Earlier quoted context omitted.
Fetch can't do a lot of table stakes stuff...
Such as?
One I’ve noticed is download/upload progress.
Post Mortem: axios NPM supply chain compromise
131–140 of 165 posts
Re: Post Mortem: axios NPM supply chain compromise
#132Earlier quoted context omitted.
NPM is designed to let you run untrusted code on your machine. It will never work. There is no game to step up. It's like asking an ostrich to start flying.
All maintainers need to do is code signing. This is a solved problem but the NPM team has been actively rejecting optional signing support for over a decade now. Even so maintainers could sign their commits anyway, but most are too lazy to spend a few minutes to prevent themselves from being impersonated.
[flagged]
Re: Post Mortem: axios NPM supply chain compromise
#133[dead]
Re: Post Mortem: axios NPM supply chain compromise
#134The fetch api has been widely available in browsers for a decade now. And in node since 18. A competent developer could whip up a more axios-like library with fetch in a day easily. You can do all the cool things like interceptors with fetch too. Yet most developers I work with just use it reflexively. This seems like one of the biggest issues with the npm ecosystem - the complete lack of motivation to write even tri…
Axios really does a lot of other great things. I would argue that Fetch could’ve easily been Axios-lite. Axios handles errors better, has interceptors, parses JSON for you, etc.
The multiple supply chain attacks against NPM packages would, of course, be solved if we simply stop using third-party libraries.
Re: Post Mortem: axios NPM supply chain compromise
#135Earlier quoted context omitted.
Nope, the most restrictive option available is to disallow tokens and require 2FA. I think that using exclusively hardware 2FA and not having the backup codes on the compromised machine probably would have prevented this attack though.
Someone in the linked Github thread describes an attack where the attackers waited for the victim to use their Yubikey for an AWS login, giving the attackers access to AWS as well. I don't think hardware 2FA is safe against a RAT.
Logins are session-based. You could tie publishing of a package to a signature from the key, then 1 tap = 1 package hash.
But yeah, if the system is compromised and the attacker is doing interactive attacks they can wait for something that requires using the key and then trigger the publishing and win a race against the real prompt. To the user it might just appear like having to tap twice.
Re: Post Mortem: axios NPM supply chain compromise
#136Earlier quoted context omitted.
With what keys, and how do you propose establishing trust in those keys? (As we’ve seen from every GPG topology outside of the kinds of small trusted rings used by Linux distros and similar, there’s no obvious, trustworthy, scalable way to do decentralized key distribution.)
If the keys that signed the early commits of a trusted FOSS project suddenly change without being signed by the previous keys, that should merit a higher level of consensus at release time, or waiting periods, etc. Identity continuity at a minimum, is of immense defensive value even though we will not know if the author is human or trusted by any humans. That said any keys that become attached to projects that are hi…
> If the keys that signed the early commits of a trusted FOSS project suddenly change without being signed by the previous keys, that should merit a higher level of consensus at release time, or waiting periods, etc.
Two immediate problems: (1) package distribution has nothing to do with git (you don’t need to use any source control to publish a package on most indices, and that probably isn’t going to change), and (2) this doesn’t easily account for expiry, revocation, or the more basal reality that most people just aren’t good at key management. I think a workable design can’t make these assumptions.
> That said any keys that become attached to projects that are highly depended on would earn a lot of trust that they are human by getting a couple of the 5k+ of people worldwide with active well trusted PGP keys to sign theirs via conferences or otherwise, as it has always been.
This doesn’t scale to graphs of hundreds of thousands of maintainers, like PyPI has. I’m also not convinced it’s ever really worked on smaller scales either, except it in the less useful “nerd cred” sense.
Re: Post Mortem: axios NPM supply chain compromise
#137Earlier quoted context omitted.
It's really not, and to the extent it is it's an echo of the nonsense filtering from elsewhere. Linux distros went decades without this kind of thing by packaging the popular stuff securely. People who wanted the source knew how to get it. The "just copy this command" nonsense absolutely came from OS X first.
Arch has pacman and that worked so well that it had to have AUR which is just glorified curl | bash. Linux distros managed it for decades when the vast majority of binaries you would run are made by nerds for nerds. If the original maintainer isn't willing to securely package it then you're often SOL.
AUR (also PPA which another comment cited) is emphatically not the same as "just run this script". If anything, and at worst, it's analogous to NPM: it's an unverified repository where the package is run at the whim of the author, and it leaves you subject to attacks against or by that author.
You still, however, know that the author is who they say they are, and that other people (the distro maintainers) believe that author to be the correct entity, and believe them to have been uncompromised. And any such compromise would, by definition, affect all users of the repo and presumably be detected by them and not by you in the overwhelmingly common case.
"Just run this script" short circuits all of that. YOU, PERSONALLY, ALONE have to do all the auditing and validation. Is the link legit? Did it come from the right place? Is it doing something weird? Was the sender compromised? There's no help. It's all on you. Godspeed.
Re: Post Mortem: axios NPM supply chain compromise
#138The fetch api has been widely available in browsers for a decade now. And in node since 18. A competent developer could whip up a more axios-like library with fetch in a day easily. You can do all the cool things like interceptors with fetch too. Yet most developers I work with just use it reflexively. This seems like one of the biggest issues with the npm ecosystem - the complete lack of motivation to write even tri…
> A competent developer could whip up a more axios-like library with fetch in a day easily. Then you would have created just an axios clone. AKA re-inventing the wheel. The issue isn't the library itself, but rather the fact that it's popular and provided a large enough attack surface. You can actually just clone the axios package and use it as is from your private repo and you would not have been affected.
I think we're entering an era where "re-inventing the wheel" is actually a completely valid defensive posture. The cost is so low relative to the reduction in risk.
Re: Post Mortem: axios NPM supply chain compromise
#139Re: Post Mortem: axios NPM supply chain compromise
#140Earlier quoted context omitted.
> NPM clients should not install freshly published packages. That would be a beautiful example of Cobra effect: what about updates that fix vulnerabilities? You're gonna force users to wait couple days or a week before they can get malware removed?
In cases like this that isn’t an issue, NPM takes the malicious package down and you roll back to the previous version. The problem would be new versions that fix security issues though, and because this is all open source as soon as you publish the fix everyone knows the vulnerability. You wouldn’t want everyone to stay on the insecure version with a basically public vulnerability for a week.
Precisely my point.