301–310 of 494 posts
Earlier quoted context omitted.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…
So does dpkg & rpm
Earlier quoted context omitted.
I didn’t take it that way at all - rather, Arch is the only one that does it “right” with the AUR.
If you want a usable system, you enable AUR. It's not 'doing it right', it's avoiding responsibility.
Earlier quoted context omitted.
You realize that "dependency cooldowns" as a popular concept are extremely new, right? npm manages the installation of dependencies for millions upon millions of users across the globe. > It could add a Hardened Security program where (1) package maintainers could opt into a program where multi-factor confirmation by maintainers is required on every publish, even those triggered by CI; Great, they did this. > And so…
What is being said is that a new flag like '--minimum-release-age' would take, realistically speaking, tops 4 hours to implement (without AI assistance), plus a good 1 week of thorough testing, and maybe a 1 month period of progressive deployment. Come on, let's give it a total of 1.5 months, for good measure. Of course this should have been started since the beginning of the major recent stream of supply chain attac…
Earlier quoted context omitted.
Let me provide context, since a bunch of people responding with "every package manager can be hit!!!" npm, by design, allows all packages to run package supplied arbitrary code as the logged-in user after an update completes. That's an INSANE default. pnpm, by contrast, allows you to essentially "opt-in" only specific packages that need this (e.g. four out of thirty, in one of our projects). Then tacks on tons of oth…
They have taken action as of very recently. The latest version [1] of npm warns when there are install scripts and tells you they will be disabled by default in a future version, with a per-dependency opt in mechanism [2]. [1] https://github.com/npm/cli/releases/tag/v11.16.0 [2] https://github.com/npm/rfcs/pull/868
To see what I mean, try actually packaging a cross-platform binary dependency in their ecosystem.
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
The package event-stream was compromised and went unnoticed for 60 days: https://medium.com/intrinsic-blog/compromised-npm-package-ev... The package axios was compromised, and hijacked the author's credentials, so every attempt at a fix was unfixed. https://www.trendmicro.com/en_us/research/26/c/axios-npm-pac... The xz utility was backdoored for 2 months: https://gigazine.net/gsc_news/en/20240403-timeline-of-xz-ope..…
Earlier quoted context omitted.
Days since last malicious packages in NPM: 0 (evergreen) Days since last malicious packages in PyPI: 30 Days since last malicious packages in Maven: 120 I'm sure this isn't 100% accurate, and there are probably better metrics (average number of malicious packages per year, average number of developers affected per year, etc) but they aren't as easy as a quick Google News search.
Except that the JavaScript / NPM ecosystem is 6-7 times larger than Python and Java / Maven. https://chatgpt.com/share/6a1da751-0d88-832e-ace7-572bc786e0... Check the linked resource which has the actual data.
Our company uses yarn 4 which has an option to prevent you from installing an npm package for the first number of days of its release. Most of these seem to be caught within that timeframe (1-3 days). https://gist.github.com/mcollina/b294a6c39ee700d24073c0e5a4e...
If everybody starts to delay for 3 days, wouldn't it be the case that everyone would discover it on the 3rd day?
I came across this interesting rant the other day: https://github.com/uNetworking/uWebSockets.js/blob/master/mi... It does make sense that the right way would be to fork every dependency you use and install from your own repo reviewing and merging from upstream as needed. Would be a giant PITA though. :)
I think the general idea that your supply chain should be rooted in source repositories and associated commit hashes is the right one. Tooling can be made to automate the process of putting together a product from those defined sources. Some languages/systems already have some support for this. E.g. Golang and Rust. The concept of a "binary" artifact is really dead now everyone uses git and builds are quick. It lives…
Hope it's ok I hijack this thread again about setting up cooldowns... (copy pasting my last comment when tanstack was compromised): I know people have opinions about cooldowns, but they would have saved you from axios, tanstack, (+ @redhat-cloud-services) and many other recent npm supply chain attacks. If you have Artifactory / Nexus, you probably already have cooldowns, but it's easy to set up if you don't. Why cool…
by now, you should have received the feedback about why cooldowns don't make sense and why nobody is adopting them. look, you are writing an expression of the reason why right there.
Earlier quoted context omitted.
Python does too I believe. Really the reason not to allow that is for robustness, not security. You ideally don't want package installs doing random stuff to your system because package authors are generally bad at doing that sort of thing cleanly. The security impact is relatively minimal because as other people have said, you just installed a package. What's the very next thing you're going to do? Compile/run it ob…
A lot of packages are pulled in to call minimal bits of the actual library. I obviously don't have any statistics on this but my instinct would say that for the average application only 5% of an average package is actually used. So not running package installation scripts is a huge, massive problem.
It is possible that not running package installation scripts could improve security, but for that you need really good sandboxing/compartmentalisation of library code, e.g. with CHERI, WASI component model, or if all of your code must run in a secure context it probably helps.
But those situations are unfortunately rare in my experience.