The only thing I take away from this is that you should not use custom domains for your email, at least for important stuff.
< 10% had useful 2FA enabled. Most were just password reset questions or had a backup email to some old expired and re-registerable forgotten earthlink accounts etc.
I do this stuff all the time. I looked up the password reset questions controlling the zoom.us domain 2 years ago and collected an insulting $200 bug bounty for it. Zoom, like NPM, didn't do signed binaries, so this would have been brutal combined with other issues I found.
The solution is what all sane OS package managers do: code signing.
NPM has rejected this at least as far back as 2013 when they refused a PR by someone that implemented it for them: https://github.com/npm/npm/pull/4016
I don't know what else to do but keep publicly trolling them at this point until code signing is implemented. Unsigned code is a free pass for remote code execution when an account gets taken over.
Meanwhile Debian maintains hundreds of signed nodejs packages proving it is very doable by a low budget team. NPM seems to just want to reduce deveopler friction at all costs :/
"Once you cross 100,000 weekly downloads, all new publishes must be signed" would keep the easy on-ramp for small packages but dramatically reduce the risk of major attacks against all the big targets (like the example here).
Not as good as signing everything, but a good start that can be iterated on later.
Most people would have no problem marking a couple of big firms and orgs as trusted reviewers and only showing packages to be used if signed by them.
For example: "ah yes, a core contributor, a frequent code reviewer, and two downstream consumers of this library have signed off on the changes in this release. even if one of them is having a distracted day/week, that's good enough for our team to be comfortable upgrading it today since it's a minor version upgrade"
You could be correct, maybe this would work in practice, trading on the reputations of those companies. It doesn't feel particularly open or community-oriented, though. Why not present a trust graph built from a broad set of worldwide users instead?
(one of the benefits to a trust graph would be the volume of signers; perhaps you wouldn't want to weight each signing equally -- again referring back to something like the distance metric mentioned previously -- but for even mid-popularity packages, the detailed review possible by careful users of a package could, I expect, be more reliable than automated-and-manual review by one or two large companies)
I don't think your trolling is doing you any favours anymore (sigh, that guy again). Kicking a dead horse etc. Maybe just let it go?
In parallel I am writing specs and proposals for widely applicable tooling and improvements.
For example: I go to release a new version and I've lost my private key, so I roll a new one -- this will happen often across npm's 1.3 million packages. Do I then ... log in with my email and update the private key on my account and go about my business? What process does npm use to make sure my new key is valid? Can a person with control over my email address fake that process? How are key rotations communicated to people updating packages -- as an almost-always-false-positive red flag, or not at all, or some useful amount in between? If you don't get this part of the design right -- and no one suggests how to in those threads -- then you're just doing hashes with worse UX. And the more you look at it, the more you might start to think (as the npm devs seem to) that npm account security is the linchpin of the whole thing rather than signing.
It's not just npm; that thread includes a PyPI core dev chipping in with the same view: "Lots of language repositories have implemented (a) [signing] and punted on (b) and (c) [some way to know which keys to trust] and essentially gained nothing. It's my belief that if npm does (a) without a solution for (b) and (c) they'll have gained nothing as well." It also has a link from a Homebrew issue thread deciding not to do signatures for the same reason -- they'd convey a false expectation without a solution for key verification.[2]
[1] https://github.com/node-forward/discussions/issues/29 [2] https://github.com/Homebrew/brew/pull/4120#issuecomment-4068...
It seems there should be some multi-factor process.
Developers need to register a password, an email address, and a YubiKey/TOTP token. If they lose access to the email address, they can log in to their account with the password and token. If they lose the token, they can be issued a new one with the email and password (or recovery codes).
As long as the account stays secure (i.e. an attacker doesn't manage to keylog the developer's NPM password and email password) then the NPM account can be trusted to add new package signing keys. The npm client then needs to trust metadata from NPM which vouches for these new keys.
The web of trust PGP signing approach works reasonably well to protect most linux servers in the world since the 90s. You can complain about it and say there should be a better UX toolchain for it, and I would agree with you. Thankfully the sequioa-pgp team has made huge progress here and it is a shame they are not getting due support for their heroic and near thankless efforts to make this better.
Still, even with todays GnuPG tools, abandoning pgp for supply chain integrity and replacing it with nothing is crazy. Imagine if we abandonded TLS because early implementations sucked. Use the best tools we have then fight to make them better. That's just good engineering.
The software eng commuity at large basically said "Look we just stopped signing code and nothing bad happened... oh wait bad things are happening. Too late to change now!"
This was a reasonably well solved problem, but entities like NPM will need to have the humility to admit that rejecting best effort cryptographic authorship attestation was a mistake.
I expect this to change. NPM will roll out mandatory MFA for the most-downloaded packages[0] (RubyGems as well[1]). I expect this will rise to a 100% requirement at some point because Github's decision to require MFA by the end of 2023 will massively raise the waterline of folks who have the capability to MFA and experience with MFA.
[0] https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...
Losing access to an account at a major mail provider seems more probable than losing control of a domain you paid for.
If I couldn’t afford that anymore, I’d probably go back to Gmail. I’d probably think to switch over many of my email addresses (for services that I use), but some may slip the cracks when the domain expires.