Comment by junon
3 months ago
Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.
3 months ago
Being able to sign releases would help, too. I would happily have that enabled since I'm always publishing from one place.
Wouldn't they have been able to change your key if they had compromised your entire npm account?
Also, junon.support++ – big thanks for being clear about all this.
Hmm, maybe npm needs to do the same thing the iPhone does now.
If you change your key you can't use it for like 12 hours or something?
Yes though in theory my public key would have been published elsewhere at least for verification. Valid point though, yes they would have been able to do that.
For this kind of infrastructure, some kind of real world verification may be necessary as well. Like having human ran phone verification (not AI, an actual call center) using information intentionally kept offline for securing more widespread and mission critical packages.
They can't pwn what they can't find online.
Push to many repos with a brand new key would (should) trigger red flags.
Good point. But how should the red flag materialize?
Provenance can be added to NPM https://docs.npmjs.com/generating-provenance-statements
So if the hacker did an npm publish from local it would show up.
Yeah; I wish provenance was more widely used. I think about this a lot for mobile apps. If you take an opensource iOS app like signal, you can read the source code on github. But there's actually no guarantee that the code on github corresponds in any way to the app I download from the app store.
With nodejs packages, I can open up node_modules and read the code. But packages get a chance to run arbitrary code on your computer after installation. By the time you can read the source code, it may be too late.