choices/choices 9.0.1 is affected by polyfill.io

Created a patch that replaces the domain based on https://github.com/Choices-js/Choices/commit/0dae0283740f4f619c7589e7b16...

There is also a polyfill.io url in webform.libraries.yml, under js for the external library webform.choices

This external library is a dependency of the webform.element.choices, which is conditionally attached in prepare() for the Select element plugin class Plugin/WebformElement/Select.php.

// Enhance select element using select2, chosen, or choices.
    if (isset($element['#select2']) && $select2_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.select2';
      $element['#attributes']['class'][] = 'js-webform-select2';
      $element['#attributes']['class'][] = 'webform-select2';
    }
    elseif (isset($element['#choices']) && $choices_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.choices';
      $element['#attributes']['class'][] = 'js-webform-choices';
      $element['#attributes']['class'][] = 'webform-choices';
    }
    elseif (isset($element['#chosen']) && $chosen_exists) {
      $element['#attached']['library'][] = 'webform/webform.element.chosen';
      $element['#attributes']['class'][] = 'js-webform-chosen';
      $element['#attributes']['class'][] = 'webform-chosen';
    }

BUT, It looks like the system will only offer one of the above, and the preferred option is Select2, so Choices is a fallback from that.

// If select2, choices, or chosen is not available,
    // see if we can use the alternative.
    $select2_exists = $this->librariesManager->isIncluded('jquery.select2');
    $choices_exists = $this->librariesManager->isIncluded('choices');
    $chosen_exists = $this->librariesManager->isIncluded('jquery.chosen');
    $default_select = ($select2_exists ? '#select2' :
      ($choices_exists ? '#choices' :
        ($chosen_exists ? '#chosen' : NULL)
      )
    );

So i think the default setup with Select2 available means this polyfill.io script isn't loaded, but it should be fixed in webform.libraries.yml, or just removed altogether since it's just one of two fallbacks from Select2.

I wouldn't remove it altogether. It's not a "fallback", it's a valid configuration option. I'm sure there's lots of sites using it.

Thank you for the patch. I've emailed the maintainer of the Choices library to request action and offer to find a new maintainer. Hopefully the related PR, which has already been reviewed and approved, will soon be merged.

Just chiming in here from a different perspective: our group has disallowed the use of Choices.js for years due to inherent accessibility issues.

Given that...

1. The software hasn't had a commit in ~3 years
2. The software ships with a vulnerability
3. The Select2 implementation ranked higher in [our] a11y testing

Might it be an alternative to deprecate / disable its use in Webform by default? Shipping what is effectively abandonware doesn't seem sustainable.

Savvy users can also utilize composer to further harden their applications:

Example: Nuke the vulnerable file from orbit on `composer install`

    "scripts": {
        "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
        "post-install-cmd": [
          "rm docroot/libraries/choices/public/index.html"
        ]
    }

🛡️

Another thing you can do in composer.json is tell Composer not to even try downloading and installing the `choices/choices` library even if it is required by another package, like webform's `composer.libraries.json`. This is informing Composer that I already have a package that replaces the functionality of all versions of `choices/choices` (even though I don't have a replacement). So, Composer will not attempt to download and install `choices/choices`..

"replace": {
    "choices/choices": "*"
}

Be aware that in case of choices 9.0.1 (contrary to the current master), which gets included by webform, the URL is *not* cdn.polyfill.io but <script src="https://polyfill.io/v3/polyfill.min.js?features=es5%2Ces6%2CArray.prototype.includes%2Cfetch%2CCustomEvent%2CElement.prototype.closest"></script> as mentioned by OP.
If you use some kind of search & replace mechanism, it should rather be something along these lines:

"scripts": {
    "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
    "post-install-cmd": [
      "sed -i 's#https://polyfill\.io/#https://polyfill-fastly\.io/#g' web/libraries/choices/public/index.html"
    ]
},

As already mentioned in [ 🐛 polyfill.io Library is no longer considered safe to use Fixed ], I'd very much favor that composer.libraries.json included this or some other form of patching the file without user interaction for the time being. Users should get a secure setup by just running composer update for their drupal installation, at least that's my way of thinking.
We can update to a fixed version later on (or switch to a better maintained lib as mentioned above) anyway.

I like the suggestion in #12 of removing the html file - it's not ideal to have random example library html pages available on your website, even if they don't have malicious scripts on them

Hello, I tried applying the patch as part of "drupal/webform" in composer.json.

"drupal/webform": {
"3457416: choices/choices 9.0.1 is affected by polyfill.io" : " https://www.drupal.org/files/issues/2024-06-27/3457416-choices-affected-... → "
}

Should it be part of "drupal/core"? After I ran composer -v install, it gave me the error:

Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2024-06-27/3457416-choices-affected-... →

In Patches.php line 331:

[Exception]

Cannot apply patch 3457416: choices/choices 9.0.1 is affected by polyfill.io ( https://www.drupal.org/files/issues/2024-06-27/3457416-choices-affected-... → )!

The patch in #7 is a patch of choices.

Thanks - that appears to have worked.
"choices/choices" : {}

Is there a way to patch it with composer?

Also, RE: #14, be aware that it's not valid JSON, as the escape sequence isn't valid. This is corrected:

    "scripts": {
        "drupal-scaffold": "DrupalComposer\\DrupalScaffold\\Plugin::scaffold",
        "post-install-cmd": [
            "sed -i 's#https://polyfill\\.io/#https://polyfill-fastly\\.io/#g' web/libraries/choices/public/index.html"
        ]
    },

Seeing as https://www.drupal.org/project/webform/issues/3460222#comment-15692042 📌 Consider deprecating Choices Closed: duplicate closed a related issue as a duplicate, I wanted to bring over the opinion that deprecating, discouraging the use of Choices, and ultimately removing it from Webform seems to be the most responsible path forward here.

The library is abandonware.

I agree that is the best solution. Anything else would be temporary.

FYI, Select2 hasn't been updated for even longer than Choices. If we're going to consider ChoicesJS abandoned, the same should be said about Select2...

It looks like a new release is being worked on for Choices.

https://github.com/Choices-js/Choices/pull/1166

A new maintainer (Xon) was added for Choices.

I've been added as a maintainer, and plan todo v11.0.0 beta/rc release early next week and will be closing out issues as they are fixed.

https://github.com/Choices-js/Choices/issues/1150#issuecomment-2270158764

a new version with the patch for pollyfill bug has been published
https://github.com/Choices-js/Choices/releases

Can we simply do a composer update choices/choices?

Wouldn't it be better to update composer.json, so that we require a secure version? I think that's best.

It's also possible that the new version breaks some things due to backwards compatibility changes. I'm not sure.

In Webform 6.3, we can upgrade libraries before the stable release.

Let's try updating the latest release of choices, which is 11.0.2.

Below are my steps to test

• Check that composer libraries work as expected
• Check that drush webform:libraries:download works as expected
• Check that CDN works as expected drush webform:libraries:remove
• Confirm Choices is loading via CDN
• Check that the Choices library is enabled ()
• Check that the Choices select menu works as expected (/form/test-element-select)

Marking this RTBC and assuming all the tests will pass.

Automatically closed - issue fixed for 2 weeks with no activity.