polyfill.io Library is no longer considered safe to use

I have created a merge request to replace polyfill.io with polyfill-fastly.io.

https://git.drupalcode.org/project/webform/-/merge_requests/419

I have also created this patch for projects that have moved on from IE 11 and no longer need polyfills.

I think this should be higher than `normal`, as it's a security threat.

Our QA team tested the patch file (not the MR) which removes the library and found no issues.

+1 for removing the library entirely, as IE 11 has been at end of support for near two years now.

+1 RTBC

The MR seems to maintain the same functionality while shifting to the more reliable/secure service. I'd recommend moving that forward. Given it's a one-line change it seems like the test failures might be related to something different.

I agree with @froboy.
Also, adding the MR diff as a patch to be used while not merged.

Since Drupal core has dropped support for Internet Explorer 11 in Drupal 10 → , I think we should remove any library that is only there for IE11 compatibility.

For users that can't wait for this to land and don't feel like patching, one can also use the libraries-override feature in their themes to remove it that way today.

libraries-override:
  webform/libraries.choices:
    js:
      'https://polyfill.io/v3/polyfill.min.js?features=es5%2Ces6%2CArray.prototype.includes%2Cfetch%2CCustomEvent%2CElement.prototype.closest%2CElement.prototype.classList': false

💪🛡️

We have also stopped supporting IE 11. Sorry I am new to this and didn't spend a lot of time looking at why the tests failed. Thank you for taking care of it.

By the way we have decided to completely remove it and suggest this as the course of action, instead of just replacing it.

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

Thanks for the work here.

I filed 📌 Create new stable release for 6.2.3 to close security issue Active about getting this into a stable release.

I would welcome a follow-up issue to remove this library entirely since IE 11 is no longer supported.

Hey Liam,

In the coming weeks I'll be doing a screen cast about our experience in theming out a somewhat complete feature set of Webform functionality.

There were a few other probable IE-isms that popped out at us (some datetime stuff, specifically). I wonder if a meta might be in order to group that effort?

Providing some guidance on how this library gets loaded since no one has yet.

Check if in /admin/structure/webform/config/libraries, Choices is enabled.

However, this setting alone won't cause the library to get loaded.

In order for it to load, a select element/field needs to have Choices checked in it's config.

The fix is either update the module to the latest version OR make sure Choices is unchecked in /admin/structure/webform/config/libraries

@#23 I think there are only a few mentions of IE in the codebase. They can probably be removed in a single issue.

I think we might need a follow-up to update the Choices library after https://github.com/Choices-js/Choices/pull/1162 lands upstream (Thanks
Jürgen!)

Presently, the choices.js library, as pulled in via `composer.libraries.json` will continue to place `./[web-root]/libraries/choices/public/index.html` on disk which loads scripts from polyfill.io. Given sophisticated enough malicious javascript, this file could potentially be used by threat actors to launch phishing attacks.

That would be a separate follow-up. Thanks

THANK YOU, No Sssweat - that is extremely helpful information!

Is it expected after an upgrade to webform-6.2.3 to still have these JS libraries source polyfill.io?

$ grep -lr "polyfill\.io" web/libraries/
web/libraries/algolia.places/src/navigatorLanguage.js
web/libraries/algolia.places/dist/cdn/places.js
web/libraries/algolia.places/dist/cdn/placesAutocompleteDataset.js
web/libraries/algolia.places/dist/cdn/placesInstantsearchWidget.js
web/libraries/algolia.places/dist/cdn/places.js.map
web/libraries/algolia.places/dist/cdn/placesAutocompleteDataset.js.map
web/libraries/algolia.places/dist/cdn/placesInstantsearchWidget.js.map
web/libraries/choices/README.md
web/libraries/choices/public/index.html

The current composer.libraries.json at https://git.drupalcode.org/project/webform/-/blob/6.2.x/composer.librari... still sources an old https://github.com/Choices-js/Choices/archive/refs/tags/v9.0.1.zip and https://registry.npmjs.org/places.js/-/places.js-1.19.0.tgz

I guess this issues should be re-opened and these dependencies removed, as well!

@tgoeg All the algolia references to polyfill.io are in comments. For example:

// not polyfilled by https://cdn.polyfill.io/v2/docs/

@tgoeg all those except for `web/libraries/choices/public/index.html` are non-functional comments essentially referencing that the polyfill code did NOT come from https://cdn.polyfill.io/v2/docs/.

While waiting on an upstream patch, @Luke.Leber mentioned over here 📌 choices/choices 9.0.1 is affected by polyfill.io Active that you can run some post composer install commands to clean it up.

I also mentioned another option in the comment below that 📌 choices/choices 9.0.1 is affected by polyfill.io Active that prevents the entire `choices/choices` library from getting downloaded in the first place. However, I think if that library doesn't exist locally on your server, then it could fallback to using the CDN library, which is the external URL that was fixed in Webform 6.2.3.

I understand all of that, and yes, there are transitional mitigations available, but why not change the root cause and stop composer.libraries.json from downloading libraries that pull in the malware-ridden version in the first place?
I don't want code in my codebase that is known to cause trouble (even if it gets an override).

This issue is closed/fixed, so I just want to raise awareness that the root cause is not fixed in my opinion.

Choices seems to be unmaintained anyway. Pull requests for fixing the issue (and others) are there, unanswered.

What about adding https://github.com/alanhamlett/Choices/commit/0dae0283740f4f619c7589e7b1... as a (local) patch in composer.libraries.json?

This would be the kind of fix I'd think of.