Remove or unpublish prism@9000.0.1

[jimmylewis]

If you search for prism, the default version returned is 9000.0.1. This is a mysterious package version; nobody knows where it came from, and it was removed from NPM back in 2019 (see https://securityreport.com/where-did-these-mysterious-prismjs-npm-versions-come-from/ for an account of the debacle).

The 9000 version is an unknown asset and should not be served to anyone.

Currently, this version is shown when initially searching for prism, or by viewing the library catalog (e.g. https://api.cdnjs.com/libraries?fields=name,version)

...
{
    "name": "prism",
    "latest": "https://cdnjs.cloudflare.com/ajax/libs/prism/9000.0.1/prism.min.js",
    "version": "9000.0.1"
},
...

Other tools which use this API to show latest versions could be sending users into a bad outcome.

[MattIPv4]

cdnjs has a very strict policy against un-publishing existing assets on the CDN, as folks may be using them directly, or be reliant on the data for them existing in the API.

That being said, I agree with working to make this not the default version recommended for the library. @xtuc / @tc80 any thoughts on the best way we can change the default version for this library? iirc we so semver sorting for auto-update, so I imagine this'll need some level of manual intervention to override?

[RunDevelopment]

I am one of Prism's maintainers and state my support for removing this version or at least not making it the default version here.

This version causes problem because some services to update dependencies use cdnJS's database to determine the latest version of a package. v9000.0.1 not only causes these services to not update Prism, they also recommend "updating" to an old, vulnerable version of Prism.

Ideally, this version should be removed outright. Nobody should be relying on this.

[ycw]

cdnjs has a very strict policy against un-publishing existing assets on the CDN, as folks may be using them directly, or be reliant on the data for them existing in the API.

@MattIPv4 reasonable ... but why the stats (of 0 vulnerabilities) is linking v1.28.0 report while v9000.0.1 is auto-picked??

[MattIPv4]

but why the stats (of 0 vulnerability) is linking from v1.28.0 report while v9000.0.1 is autopicked??

The Snyk integration on the page is given the library and version that is picked. If you watch the network calls being made, you will see that we are sending the version that is picked (v9000.0.1). You'll need to take this up with the Snyk team if it isn't returning the results you expect 👍

[FlipperPA]

This version is still available on CDNJS and is still a security vulnerability. You're only making the problem worse by continuing to host this version, especially since it is still selected as the default. C'mon CDNJS, I appreciate your service, but you have more responsibility than this: you're actively hosting a known insecure package as the default. @MattIPv4 @xtuc @tc80

I maintain a downstream package and had to code around this to avoid it being picked up as the "latest version." Not all downstream consumers of the package may have caught this, which would propagate the security vulnerability further downstream.

[MattIPv4]

cdnjs will NOT remove a file, it will break websites. I am sure there are plenty of files on the CDN that contain vulnerabilities, that is the nature of code. We don't remove them though, because folks might be using those files on their websites and we don't want to break them.

As I said above, before, I agree that we need to fix this so it isn't listed as the latest version though. This has been on my list of issues that need Cloudflare's attention for over a year now. I'm sorry there is no further progress on this, but until Cloudflare or someone from the community puts the work in to update the auto-update bot logic to allow versions to be excluded from being shown as latest, this will remain an issue.

[FlipperPA]

@MattIPv4 We have similar discussions as part of the PyPA, but allow users to remove accidentally published files on PyPI... albeit with plenty of warnings before deletion. GitHub does the same with repository deletion: lots of warnings. Our calculus is that it is best to allow the removal of accidental publishes containing vulnerabilities and exploits, rather than allowing them to propagate, even at the cost of breakage. It is about making the "less bad" decision. While I respect your choice, I encourage CDNJS to reconsider this policy, especially since there's been over a year waiting for a solution that would make the current status "less bad." Again, I thank you for your service, and don't mean this to sound hostile.

Here's the interface we use on PyPI:

[MattIPv4]

Fwiw, I think those cases are both slightly different from cdnjs -- Python package versions and GitHub repositories likely aren't being consumed continually at runtime for something, they're generally referenced during builds etc. That is to say, pulling one down likely won't break an end-user in a system somewhere, it'll just break the next build of said system. With cdnjs, these files are pulled directly into websites every single time an end-user loads the page, so the second we remove a file, we break those pages for those users. There is no build system in the middle that'd allow website owners to catch it before it broke their sites for users.