441–450 of 494 posts
It will only get much worse because popular AI coding harness (OpenCode/KiloCode) will just download random npm packages in the background without you knowing. And the devs don't care. Setting min age is useless if everyone is doing it. The whole point of setting min age is make someone else take the bait before you.
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. There's plenty of comments mentioning delay lines, and the other good stuff pnpm (and others) have implemented in response to protect package consumers. That bit that's getting less conversation is the tools on the package maintai…
I mean it keeps happening lmao. You can track npm attacks these on a calendar. Someone made a npm parody of the classic "no way to avoid this" The Onion article.
It's great there's work to stop it all but also... it keeps happening. I find it funny in a "here we go again" way.
Earlier quoted context omitted.
From that repo: > Exact version pinning — specifying precise versions (1.0.0, ==1.0.0, =1.0.0, = 5.31.0) rather than ranges (^, ~>, >=) in package manifests. Ranges allow any version satisfying the constraint to be resolved at install time; exact pins mean only one version is ever valid. My understanding is that pinning the dependency within the manifest isn't the mechanism that prevents the version from changing acr…
Specifying precise versions is sufficient to ensure that the packages in your package.json are installed in the pinned versions. The problem solved by lockfiles is second, third and n-order dependencies. Just because you pinned precise versions does not mean react or vue or whatever random package you installed did as well. That's where the lockfile comes in, it pins the dependencies of the dependencies.
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. :)
Gentoo graybeards know.
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. :)
The problem is the volume of dependencies. Most modern JavaScript, Python, Rust, Go, etc. projects have many dozens of transitive dependencies.
I've made it a habit now to use the --before=2026-05-30 flag when installing packages, where it'll pick the version released before the date you specify, I usually pick around 5 days ago
Yarn 4 can automate this
Go look in that projects issue tracker and commit log for changes to relevant configuration and you will know what I mean.
Even yarn 1.22 is a safer choice.
Quote:
> The affected packages are frontend libraries that are compiled and bundled into some container images during the Red Hat product build process.
So you might be affected if you deployed any Red Hat container images built after the compromise, I guess. (I doubt anyone besides Red Hat is using the affected packages directly.)
Devs and other people who have seen behind the scenes at large companies know that most security is at best shaky and mostly hand-waved It’s not even really the fault of the people who pushed for these setups, it’s a seemingly simple business decision: build it in a way that looks secure, add some black-box process, and tell the overseers that the reason there are no attacks is because it’s bulletproof, and definitel…
Earlier quoted context omitted.
As an embedded dev who’s used to locking to toolchains and deps for years at a time, web dev is a culture shock in so many ways.
There's literally no excuse - I'm still baffled.
And what's a proper cooldown? 1 day? 3 days? 1 week? 1 month? If you have a vulnerability, now you're exposed during that cooldown period. There's no straight forward or easy answer here.
I am speaking from my own experience here with having to sit in during these discussions where security "advice" is provided to the development team without understanding what it entails or any tradeoffs. I found that keeping things relatively secure is hard work and needs to be a part of culture.
Earlier quoted context omitted.
IMHO those are both lipstick on a pig solutions. Ultimately all this stuff is just a variation of "make releases harder to publish", which isn't going to do anything but train people to evade them. Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. The bug here isn't that we need to better authenticate…
> Notably, neither would have prevented the xz-utils backdoor from reaching package distribution, which remains the gold standard for sophisticated upstream compromise. Mandating that the final binary is compiled without having any access to any test file though would have prevented the xz-utils backdoor as it was conceived though. A proper packaging setup would first verify that all the tests are passing and happen…
It would, but I'm not seeing that as a suggestion? That was a very clever side channel for hiding the build-time payload. It wasn't remotely the "root cause" of the exploit, which was that a malicious actor got write access to the release process of trusted software. I mean, if you can do that, you can surely find other clever ways to hide your junk.
To wit: you're not wrong, you're just stuck on minutiae. By all means make the case, but at best you're proposing a small constant factor optimization.