Polyfill.io is no longer considered safe and should be removed

Replacements for the library can be found here:
https://community.fastly.com/t/new-options-for-polyfill-io-users/2540

https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-yo...

Latest Leaflet 10.2.12 release → indeed (already) fixed this security issue,
changing the reference to the Polyfill.io library by pointing to the https://polyfill-fastly.io/ domain
as discussed and suggested here: https://security.drupal.org/node/180274

Please also look the related Advisory for this Leaflet security issue: https://security.drupal.org/node/180276

I can still see it being used in version 10.2.12

https://git.drupalcode.org/project/leaflet/-/blob/10.2.x/leaflet.librari...

# External IntersectionObserver polyfill
intersection_observer:
remote: https://polyfill.io/v3/polyfill.min.js?features=IntersectionObserver

It does look like there's still a link left to polyfill.io.

@itamair. Thanks for the links to the security issue, but I get this message:

Access denied

You are not authorized to access this page.

Thanks @ressa ... your contribution is always super valuable and pertinent.
I fixed your lates remark in the lates commit, that will be part of the next Leaflet 10.2.x release.

Here under is the description of the security issue and correspondent workaround suggested here: https://security.drupal.org/node/180274

This module has a potentially malicious 3rd party JS vulnerability.

You can see this vulnerability by:
1. Enabling the module
2. polyfill.min.js is included via the polyfill.io domain.

"As of February 24, 2024, cdn.polyfill.io, the domain hosting the polyfill.io JavaScript library, has been acquired by a Chinese company named Funnull. Polyfill.io is a widely used JavaScript library integrated into many of the world's most well known web applications. All polyfill.io traffic is now pointing to the Baishan Cloud CDN (https://www.baishancloud.com/)."

https://polykill.io/
https://github.com/polyfillpolyfill/polyfill-service/issues/2834

Both Fastly and CloudFlare have provided temporary fixes for this issue
https://blog.cloudflare.com/polyfill-io-now-available-on-cdnjs-reduce-yo...
https://polyfill-fastly.io/

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

Comment #3 links to https://security.drupal.org/node/180276 which was a private issue (that will remain private) where there was discussion and it was agreed this could be handled in public.

Thanks Drupal security team for looking into this, and @itamair for removing this third-party library. For now polyfill-fastly.io looks safe, but what happens if Fastly is bought up and closed, goes bankrupt, or something else ... and the domain is squatted in two years time, just like polyfill.io was?

Currently on the "Policy on 3rd party assets on Drupal.org > Third party libraries" page it says:

Having third party libraries that are hosted elsewhere on the Internet in the Drupal.org repo is strongly discouraged. Instead, if the library in question is available under GPLv2+, or has a “GPL-friendly” license (see note below), you may use one of the methods described on the community documentation page titled “ Including 3rd party libraries → ”.

From https://www.drupal.org/node/422996#libraries →

As I see it, it could make it simpler for module maintainers like @itamair, if it wasn't strongly discouraged to include a small library such as the Polyfill library (200 kB) in the Leaflet module ... This would reduce the risk, with little downside.

Yeah it's a balance, and I don't think there's a clear "right answer" at present.

Putting a static copy of the library in the module mitigates supply chain risk, but on the other hand if/when a vulnerability is found and fixed in the (upstream) library... we then need to find all copies of it everywhere and update them (or backport the fix).

Which problem is worse?

Referencing dependencies with tools like composer (and perhaps npm in the future?) has the advantage that it makes automated auditing easier (dependabot etc..) and potentially sites can update themselves without relying on Drupal projects doing new releases (that's subject to appropriate constraints being in place, and everyone's interpretation of semver agreeing etc.. etc..)

I agree, it's a balancing act -- but the wording is very much in favor of using third-parties:

Having third party libraries that are hosted elsewhere on the Internet in the Drupal.org repo is strongly discouraged.

This wording could be relaxed a bit, to something like this:

Third party libraries hosted elsewhere on the Internet can be included in the Drupal.org repo, though it's not recommended.

I also agree with this:

Putting a static copy of the library in the module mitigates supply chain risk, but on the other hand if/when a vulnerability is found and fixed in the (upstream) library... we then need to find all copies of it everywhere and update them (or backport the fix).

It might not be an option, due to licensing, or some other structural blocker I am not aware of -- but the Drupal community could make a handful of Composer packages for the most popular JavaScript libraries, so that a module maintainer could require drupal/javascript-polyfill and always get the latest, safest version. NPM is an option, though I do prefer Composer if it's possible, since that's already used by everyone and well known. I am sure this has been discussed at length in other issues :-)

Probably good to mention, polyfill.js only seems to get loaded when using Lazy Loading (map_lazy_load), see https://git.drupalcode.org/search?search=intersection_observer&nav_sourc....

Hi folks @here!

According to the all above discussion and worth inputs, and to the fact that the IntersectionObserver polyfill library is only loaded in case of Leaflet Lazy Loading, and effectively used in case of very old Browsers (that natively don't support the IntersectionObserver API),
I decided to local embed the remote/External IntersectionObserver polyfill library into the Leaflet module,
so to avoid any future security and reliability issue related to Polyfill.io js library.

The new just deployed leaflet 10.2.19 release → is indeed embedding the remote/External IntersectionObserver polyfill library into the Leaflet module itself.

Hopeful and confident that this makes a lot of sense (and improves/fixes module security issues on all of this)
Please feel free to open a new follow-up issue for any new issues related to any of this ...

Thanks @itamair, including the IntersectionObserver polyfill library in the Leaflet module seems like the pragmatic solution in this case, for the reasons you outline.

I have Leaflet 10.2.19 installed, and I know the IntersectionObserver polyfill JS file is now locally included, but I'm still seeing a link to this remote repo:

# Local IntersectionObserver polyfill
intersection_observer:
  remote: https://github.com/polyfillpolyfill/polyfill-service/blob/main/polyfill-libraries/3.110.1/IntersectionObserver/raw.js
  version: 3.110.1
  license:
    name: MIT License
    url: https://www.w3.org/Consortium/Legal/2015/copyright-software-and-document
    gpl-compatible: true
  js:
    'js/polyfill/polifillIntersectionObserver.js': { minified: true }

... github.com/polyfillpolyfill/polyfill-service which is flagged byGitHub as:

"This repository contains malicious content that may cause technical harms. We have decided to preserve this content for security research purposes. Please exercise CAUTION when clicking links, downloading releases, or otherwise interacting with this repository."

So, should that be removed from the module too?

Ok ... totally done (and kind of fed-up) with this polyfill.io library drama,
I deployed a new Leaflet 10.2.20 version → that
removes injection of polyfill/IntersectionObserver js library all the way, for backward support to very old browsers
and adds IntersectionObserver Browser Compatibility check disclaimer in the View and Formatter settings (https://git.drupalcode.org/project/leaflet/-/commit/a6d53ccc14c8a7500aeb...)

because:

• polyfill/intersectionObserver js (polyfill.io) library is only needed with very old browsers versions (and its effectiveness is not really proven);
• Leaflet Map Lazy Load is going to fallback to normal Leaflet Map load, if the browser don't support the 'IntersectionObserver' API/object;
• polyfill/intersectionObserver js (polyfill.io) library is no longer considered safe to use (@see https://www.drupal.org/project/geofield_map/issues/3456704 📌 polyfill.io Library is no longer considered safe to use Fixed ) and https://github.com/polyfillpolyfill/polyfill-service/issues/2892)

Issue (double) closed!

It always feels good to clean up, and get rid of old stuff, which is probably not needed anyway. So something good came out of this in the end. Thanks @itamair.