Pnpm has a new setting to stave off supply chain attacks
21–30 of 152 posts
Re: Pnpm has a new setting to stave off supply chain attacks
#22If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
Re: Pnpm has a new setting to stave off supply chain attacks
#23I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…
In 2 months, a typical js framework goes through the full Gartner Hype Cycle and moves to being unmaintained with an archived git repo and dozens of virus infected forks with similar names.
Re: Pnpm has a new setting to stave off supply chain attacks
#24That solve not really the problem. A better (not perfect) solution: Every package should by AI analysed on an update before it is public available, to detect dangerous code and set a rating. In package.json should be a rating defined, when remote package is below that value it could be updated, if it is higher a warning should appear. But this will cost, but i hope, that companies like github, etc. will allow package…
Ah, yes! The universal and uncheatable LLM! Surely nothing can go wrong.
Re: Pnpm has a new setting to stave off supply chain attacks
#25how about requiring some kind of interaction if they want to run an install script?
Re: Pnpm has a new setting to stave off supply chain attacks
#26I have a question: when I’ve seen people discussing this setting, people talk about using like ”3 days” or ”7 days” as the timeout, which seems insanely short to me for production use. As a C++ developer, I would be hesitant to use any dependency in the first six months of release in production, unless there’s some critical CVE or something (then again, we make client side applications with essentially no networking,…
Really depends on the context and where the code is being used. As others have pointed out most js packages will use semantic versioning. For the patch releases (the last of the three numbers), for code that is exposed to the outside world you generally want to apply those rather quickly. As those will contain hotfixes including those fixing CVEs.
For the major and minor releases it really depends on what sort of dependencies you are using and how stable they are.
The issue isn't really unique to the JavaScript eco system either. A bigger java project (certainly with a lot of spring related dependencies) will also see a lot of movement.
That isn't to say that some tropes about the JavaScript ecosystem being extremely volatile aren't entirely true. But in this case I do think the context is the bigger difference.
> then again, we make client side applications with essentially no networking, so security isn’t as critical for us, stability is much more important)
By its nature, most JavaScript will be network connected in some fashion in environments with plenty of bad actors.
Re: Pnpm has a new setting to stave off supply chain attacks
#27Should have included the units in the name or required a choice of unit to be selected as part of the value. Sorry, just a bugbear of mine.
Re: Pnpm has a new setting to stave off supply chain attacks
#28Re: Pnpm has a new setting to stave off supply chain attacks
#29If everyone is going to wait 3 days before installing the latest version of a compromised package, it will take more than 3 days to detect an incident.
A lot of people will still use npm, so they'll be the canaries in the coal mine :) More seriously, automated scanners seem to do a good job already of finding malicious packages. It's a wonder that npm themselves haven't already deployed an automated countermeasure.
> It started with a cryptic build failure in our CI/CD pipeline, which my colleague noticed
> This seemingly minor error was the first sign of a sophisticated supply chain attack. We traced the failure to a small dependency, error-ex. Our package-lock.json specified the stable version 1.3.2 or newer, so it installed the latest version 1.3.3, which got published just a few minutes earlier.