Live data from Hacker News

Post Mortem: axios NPM supply chain compromise

github.com

151–160 of 165 posts

Re: Post Mortem: axios NPM supply chain compromise

#151
post #69

Earlier quoted context omitted.

npm process to setup OIDC is way too frustrating. There is just so much friction. You need the package to first exists in the registry, meaning you have to first create an API token and push something. And only then can you enable OIDC for that specific package. After adding the repo + workflow names, you have to save. Then finally toggle the “only allow OIDC publishing”. Before each action you need to enter your 2fa…

You’re right, but a colleague recently showed me this CLI for it: https://docs.npmjs.com/cli/v11/commands/npm-trust Still needs to be published first, but looks like it automates all the annoying UI things you mentioned.

Oh that’s neat! Thank you for sharing!

Re: Post Mortem: axios NPM supply chain compromise

#152
post #22
post #8

Not much we didn't know (you're basically SOL since an owner was compromised), however we now have a small peek into the actual meat of the social engineering, which is the only interesting news imho: https://github.com/axios/axios/issues/10636#issuecomment-418...

An owner being compromised is absolutely survivable on a responsibly run FOSS project with proper commit/review/push signing. This and every other recent supply chain attack was completely preventable. So much so I am very comfortable victim blaming at this point. This is absolutely on the Axios team. Go setup some smartcards for signing git push/commit and publish those keys widely, and mandate signed merge commits…

The "nothing gets on main without two signatures" rule would not have prevented the xz story, where a comaintainer was able to smuggle malicious code past the review as "binary data for new tests" and, effectively, get it signed.

Re: Post Mortem: axios NPM supply chain compromise

#153
post #86

Earlier quoted context omitted.

What they need to mandate is hardware anchored passkeys/fido2/webauthn for both auth and package signing, with the -option- to sign with PGP for those that have well trusted PGP keys. They won't do this, I have talked to them plenty of times about it. But, if they did, the supply chain attacks would almost entirely stop.

Don't need to require hardware 2fa tokens. Just a mobile app would be sufficient. Publish to a staging area then require confirmation on mobile to make it go live. Maybe include a diff of changes files for good measure.

And even a mobile app (or, in fact, any single-person 2FA) would be unnecessary if we had a requirement for another live person to approve the release. As a bonus, a two-maintainers-required setup would also improve resilience against one of them going rogue or getting tortured.

Re: Post Mortem: axios NPM supply chain compromise

#154
post #18

I ask this on every supply chain security fail: Can we please mandate signing packages? Or at least commits? NPM rejected PRs to support optional signing multiple times more than a decade ago now, and this choice has not aged well. Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software. Normaliz…

> Anyone that cannot take 5 minutes to set up commit signing with a $40 usb smartcard to prevent impersonation has absolutely no business writing widely depended upon FOSS software.

No. As a user of your package, I want assurance that the package you publish does what it says it does and does not contain malware. This is different from the package having been published by you. I want protection against you going rogue, not only from you being impersonated. 2FA on your side does not protect me against you going rogue. A comaintainer does.

So the correct quote would be: Anyone that cannot find a comaintainer to review all the code and to prevent deliberate sabotage has absolutely no business writing widely depended upon FOSS software.

Re: Post Mortem: axios NPM supply chain compromise

#155

Earlier quoted context omitted.

Such as?

One I’ve noticed is download/upload progress.

You’ve been able to do download/upload progress using the Streams API with fetch for more than seven years now. https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

Re: Post Mortem: axios NPM supply chain compromise

#156
post #155

Earlier quoted context omitted.

One I’ve noticed is download/upload progress.

You’ve been able to do download/upload progress using the Streams API with fetch for more than seven years now. https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

on the FE?

Re: Post Mortem: axios NPM supply chain compromise

#157
post #134

The 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.

parse json?

const x = await fetch(...); await x.json();

"intercept" code that runs before every request?

const withAuth = (res, options) => fetch(res, { ... do stuff here });

Re: Post Mortem: axios NPM supply chain compromise

#160
post #155

Earlier quoted context omitted.

You’ve been able to do download/upload progress using the Streams API with fetch for more than seven years now. https://developer.mozilla.org/en-US/docs/Web/API/Streams_API

on the FE?

The streams API exists on the FE, you can pipe an upload or download through a TransformStream to monitor progress
Post reply on HN