251–260 of 494 posts
Earlier quoted context omitted.
The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.
Let’s not ignore that dependencies are far more common in JS than any of those other languages. My Go or Python projects generally only include a handful of external packages. Node projects on the other hand…
Earlier quoted context omitted.
How large a project do you typically use dotnet for? IME dotnet dependency situation is a tire fire, not a month goes by without another dependency biting the dust or going fully commercial with no notice. Which is fair, I suppose, but Go and Java ecosystems don't have it nearly as bad.
I don't think going commercial has been that impactful. It sucks, it betrays the spirit of open source but whatever. A few examples: - FluentAssertions had no moat, and it has been forked as AwesomeAssertions. Not sure what the author's play was here. - Moq lost trust - we have NSubstitute - AutoMapper and MediatR have been widely misused anyway - Maybe MassTransit is a real bummer?
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…
i've been thinking about this as well. but having built a startup, i've learned that users don't care as long as they are given the value and most convenience. they don't really care much at security as much as we do. just look at openclaw? but maybe it's our job to make sure it is taken care of vs assuming the user cares and just make it look seamless.
security is a hidden requirement.
Earlier quoted context omitted.
Nearly every package manager I've ever used had post-install scripts. Most run as root, since that's what usually what the package manager runs as. It's not unreasonable: you're already installing software, which presents risks. If post-install scripts were not a thing, a payload could still run because you ran the software you installed. Or because the installer added it to auto-run. Or because the installer placed…
Most package managers with postinstall scripts are also heavily curated and have reputation systems. As you say, they run as root, so the high trust requirement is definitely warranted. Anyone can upload an npm package.
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..…
Many automated scanners use static code analysis rather than run the installation script. Not all of them are caught, but a good part of them are and you'd be saved by a delay.
Earlier quoted context omitted.
There are so, so many things that NPM could do. It could require a 48 hour cooldown period on any package update that wants to add an install script that didn't have one before, and has a certain number of downloads. And it could publish the list of these so security researchers have an opportunity to scan them. It could add an optional key to package.json that allows someone to whitelist which packages can run insta…
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…
Of course this should have been started since the beginning of the major recent stream of supply chain attacks, circa 2024 or 2025... but even assuming the most backwards calendaring possible -starting after the last bug compromise (Axios, on March 31st)- that new flag should have already been shipped a couple weeks ago.
Shit does take time, but where there's a will there's a way, and nobody buys that this shit would take that much time.
Earlier quoted context omitted.
The problem would be the dependencies of your dependencies, and keep going many levels.
The problem is that node.js doesn't have a good standard library so one must rely on external packages to build even basic apps.