Top-500 NPM package maintainers now require 2FA
github.blog
github.blog
This is great news. Some years ago an ethical hacker hacked me. I can still remember my shocked reaction upon being contacted by the hacker in question where I learned they now had the ability to publish malicious versions of npm packages on my behalf. This was long before supply chain attacks were well known and commonly discussed. A more innocent time.
The hacker in question gave me a simple piece of advice: turn 2FA on for your packages. Which I subsequently did. It's great that npm are pushing this. Yes it's a faff but the tradeoffs are net good. A little inconvenience is reasonable as compared to the alternative possibility.
I remain very grateful to the person who hacked me. If you should be out there: thanks - you did me a service
How did they do that?
I fail to see how MFA resolves the fundamental trust equation. Bad code is bad code, doesn't matter what the authentication system says about the actor's identity. I can create 2FA-enabled GH accounts all day named after JK Rowling characters without anyone at GH sending me a security nastygram or banning me for identity violations.
Until GitHub requires government-issued photo ID in addition to MFA, I don't think you are going to properly discourage bad or criminal actors. To be clear: I strongly disagree with any notion that GitHub should require photo ID to open an account. But, perhaps a "verified user" option (extending to "verified org" if all users are compliant) might provide another path.
As a nice bonus, this is a great way to stop people from contributing to projects for free out of the goodness of their hearts. /s
I guess it might be problematic if you want to contribute to politically controversial stuff.
I was simply challenging the assertation that contributions would dry up when required to identify yourself, and I don’t think that’s true. I can’t be the only one that has only a mildly pseudonymous account.
An individual may choose to not be an unpaid yet completely exposed part of such a professional supply chain, to be pressured and shamed in real life by whoever sees fit to do so. There should be such a supply chain, by all means, run by companies for companies with paid or otherwise fairly compensated contributors, vetted and named and identified and badged and protected by corporate legal, but I'm quite sure forcing the wider open source community into that mold would destroy most of what makes it so successful.
For my part, I do a little open source for fun in my free time. That works for me because I'm reasonably anonymous, i.e. any mishaps or bad blood from entitled users can't really affect me in other ways. Bugs happen, stupid security fuck-ups happen, irrational demands happen, but all that can reasonably do is burn my GitHub identity.
That's important to me, I'm not out to build another stressful career as an unpaid provider of first-class software and services, I just sometimes share what I build for myself anyway. If every single thing I do is transparently connected to my real identity, I'll move everything I do to my private Gitea and it'll stay there. That's no big deal for the general public, none of my things are very popular or important, but I guess others will feel the same and their stuff might be. I'd hate for this to die because greedy corps want their free labor to happen in a panopticon.
What does that really matter, though? You could ask the same of _any_ modern application, NodeJS or otherwise: "On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern application?". Look at your web browser alone. You have an open source rendering engine. The JavaScript engine. The underlying libraries used to handle things like SSL, TCP/IP, DNS lookups. It runs on an OS that likely has layers and layers of open source code. Which runs on hardware from various manufacturers with firmware written by many people spread across many organizations.
> I fail to see how MFA resolves the fundamental trust equation
Nothing ever will. Your desire for a cathedral is incompatible fundamentally & at every level with the bazaar.
Trying to drive open-source society towards an industrialized security state for the convenience of your probably non-contributing, not-paying industrialized software production needs is vastly unfair.
If you have needs, you need to take your own responsibility. If you have risks, you need to pay to hedge them. Go hire NodeSource to help you get the Certified Modules you can trust. Go sign contracts with authors to get the support you need. Heck, just checkin your package-lock.json and go see what you are downloading: npm is immutable! You could literally do anything to help safeguard yourself, but you ask for absolute protection, something that even the biggest best corporations can never truly promise. Trying to prevent even one reasonably placed malicious employee from causing disruption is a near impossible task. But you ask for a fundamental safety. This is laughable. None of us can expect nor deserve that.
> Until GitHub requires government-issued photo ID in addition to MFA
What a vile & fascist imposition this would be! Woe be unto us if industrialzied software so hotly presses for it's own security that it embraces such ludicrous & perverse a cowardice as this. Relying on github as your source of trust, and pressuring them to pressure the world into turning over core information, is just as antithetical as I can image to the open source behavior & society that has advanced us so far. What a terrible thing to wish for! Egads, gross.
[1] https://blog.sigstore.dev/privacy-in-sigstore-57cac15af0d0 https://news.ycombinator.com/item?id=31533997
Ultimately problems with your code, including deps it pulls in, are your problem, no one else's. Code appropriately.
But I also think top-down, authoritarian measures are pitiful, reactionary, & an entitled response. This co-option & bending- of what has gotten us so far, & only infrequently been problematic- into something industrial & controlling, is unwarranted & vulgar.
It's very important to realize that "success" cannot be the objective. There will always be fundamental questions of trust that are outstanding. Once we begin pretending that this is a "problem to be solved" and not an ongoing shifting changing scene we think too short-term, too limitedly. This is a long long iteration with no finality with no triumphant final cracking the code to get us security. Letting Microsoft and/or China[1] approve all PRs & everyone living happily ever sounds nice, but incompatible with the ethos & logos of open-source, of letting people be people & mutually encouraging each other.
I'd also emphasize- strongly- that the real defenses are collectivized ones. Maybe we can build a social network of vouchers, people who look at releases & record a confidence or sureness they feel about the changes. Aggregate the results when we update packages. Open source has been a collective effort, and I think a lot of the security gains we want are from increased collectivization. This- notably- again bucks the idea of absolute security, of fundamental answers, and instead encourages & pushes in a good direction.
[1] https://www.scmp.com/tech/big-tech/article/3178323/gitee-chi... https://news.ycombinator.com/item?id=31458770
My take on that is more like:
Your bosses desire for you to build them a cathedral without doing most of the required work, by piling up free foundations, walls, pulpits, pipe organs, arched ceilings, spires, and left pad.js - that other people will give you for free, is a fundamentally flawed plan which will inevitably lead to things not fitting together quite right and ending up with something much more like a bazaar, that is significantly less beautiful and secure than the cathedral in the pitch deck.
Most "serious" packages in Maven Central do have a dedicated DNS, for instance, even though there's the fallback of using io.github.username as the namespace. I feel like providing a namespace and starting to incentivize for it to correspond to a real DNS would be a good start.
this is absolutely dystopian. Please don't give microsoft any more ideas.
What about software developers that don't drive?
This suggestion sounds like a way to create new and far bigger problems without doing anything to solve the original problem.
Let's keep the problem in perspective, shall we? You want to freely access code contributed by someone over the internet, and you want to trust it's provenance. This does not change at all if you throw government-issued IDs into the mix, nor does this affect any of the attack vectors exploited by bad actors.
Apparently it's too trivial for a release but the maintainers still seem to be around. Substack.net listed in package.json seems to be working: https://substack.net/cv.html
I feel like at this point continuing to publish on npm is kind of a "that's what you get" situation.
This sucks, but invalidating the pre-2FA tokens is unavoidable if their goal is to tighten security of top packages. I don't know how this went down behind the scenes, but hopefully they announced giving you some long enough window like 60–90 days before the old tokens were invalidated.
However, what does invalidating your old tokens have to do with signing into the web app that uses your username and password?
https://github.com/SheetJS/sheetjs/issues/2667#issuecomment-... (archived: https://web.archive.org/web/20220510110516/https://github.co... )
>Due to ongoing legal matters between SheetJS LLC and npm, Inc. (which will not be discussed here), it did not make sense to continue using the public npm registry for distribution.
> npm inc invalidated all of our authentication tokens in mid April and we have been unable to sign in via the web interface since then.
Get a yubikey[0], that way you don't need a phone.
I find the recent push by big tech and others to discredit open software solutions like PGP suspicious. Banks push out new apps on a yearly basis, we are supposed to insert USB sticks to contribute to open source. Big tech rarely acts in your best interests.
Sure, if your computer gets owned, it won't help, but it's still much better than nothing and practically free.
- Locked out of npm because I don't have the 2FA key anymore
- Recover my 2FA with my email (which totally defeats the point of 2FA)
- Be asked for some gvmt ID to proof who I am (again a no-no)
In case you don't, you can write down the seeds of the OTPs on a piece of paper. Which you leave at home or at a friend's house or similar. The principle being that you won't lose both your laptop and piece of paper at the same time.
edit: for a "good enough" approach you can probably store your 2FA codes in your password manager, for which you have, presumably, some kind of backup.
Maybe ther should be a paid service that would manually review packages and provide a curated repository? I can't see other solutions. Either you review the code or you pay someone to do it or you isolate every library into a sandbox.
I don't really get why all these package managers don't copy this from the Java world.
If you generate a “CI Token”
On npm. Anyone can still publish packages as you if they get ahold of it.
No 2FA needed
Signing is all well and good, but it doesn't do anything to demonstrate that the signed contents were prepared by a particular person. It only means they probably came from one of a set of computers.
If they had adjusted to uploads require a hardware backed challenge pass, I'd be much more enthusiastic. Releases don't happen that often, adding a step to demonstrate presence to it would not be a huge burden.
From npm.
Does this no longer apply? People can't publish from CI anymore as 2FA is now required?
a move in the right direction
also they should deny new IPs (other than different subnets) until real person verification
https://github.blog/2022-05-10-enhanced-2fa-experience-for-y...
It looks like the plan is to roll it out to any package with some amount of traction.
this ain't gonna do shit about Kony 2022 activism either, which is definitely going to be the next big thing