javascript-clients VS Nuget Package Manager

List of affected packages: https://github.com/RedHatInsights/javascript-clients/issues/...

This repository itself had to previously update from the axios supply chain attack [0] (co-authored by Claude lol). But just by looking at the change itself, the package is unpinned and won't solve the problem if it happens again as a illegitimate "security update".

So if you have an unpinned version of this package and you run 'npm install', you immediately downloaded the compromised version and that's that.

[0] https://github.com/RedHatInsights/javascript-clients/commit/...

>> In every of these threads there's a bunch of snarky comments, either acting like this class of attack is exclusive to npm, or that nothing has been done about it. I don't think that's fair.

> … the classic "no way to avoid this" The Onion article

But isn't point of The Onion article that A) the US has >50x as many incidents as the rest of the developed world combined [1], and yet B) acts like there is "no way to avoid this". Does NPM have >50x as many incidents as the rest of established languages combined? Is NPM claiming there is "no way to avoid this" or are they putting in place things like automatic install delays?

While all the major js package managers already support install delays, none of the big local C#/dotnet/nuget apps do (Visual Studio/Rider/nuget/dotnet/VS Code). https://github.com/NuGet/Home/issues/14657

[1] https://edition.cnn.com/2018/05/21/us/school-shooting-us-ver...

The performance gap can be staggering. NuGet/Home Issue #11548 documented a case where dotnet restore took 5 minutes 39 seconds on Windows versus 16 seconds on Ubuntu for identical packages — because Windows was performing synchronous certificate revocation checks. Setting NUGET_CERT_REVOCATION_MODE=offline dropped it to 1 minute 22 seconds.

However, any client dependency can lead to a future case of the notorious "DLL hell" problem. While multiple major versions of the same package are transitively referenced by the root application, we have exactly one package version bound at runtime. Then, when we call the other version transitively, we can get a nasty runtime error. In general form, it is unsolvable on the root application side. More technical details can be found, for example, in this thread and its follow-ups: Referencing multiple package versions within one project with extern aliases.

- https://github.com/NuGet/Home/issues/8843

GitHub Issue

Similar issue here: https://github.com/dotnet/sdk/issues/28971. Following the breadcrumbs it looks like it may be a NuGet issue, reported here: https://github.com/NuGet/Home/issues/12227

Your issue appears to be related to not having the appropriate permissions to the Nuget folder (so says the error). There is an existing Bug/Ticket open on the Nuget github for this exact issue. There are a few solutions and/or workarounds listed through the conversation that you can try: https://github.com/NuGet/Home/issues/12162. Unfortunately I do not have a Mac to validate the solutions or the issue myself.