I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project?
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.
How so? I’m already contributing with an account that is astoundingly easy to resolve to my real name. Adding government issued ID to that equation would change nothing for me.
I guess it might be problematic if you want to contribute to politically controversial stuff.
Nowhere do I say that nobody has anything to hide. Hell, I have stuff to hide, but none of that is connected to my public Github account.
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.
Is the assertion here that people who have a troublesome family history, or a stalker, or debt, or who wish to change their lives, or are from a place where their social or racial group might be persecuted, or who simply wish to write code separately from their day-to-day, should not be allowed to do so?
It's nice that you Have Nothing to Hide, but not everyone wants to - or can - live like that. It's not just politically sensitive stuff (though that's a good reason); some of us like having privacy, and there's no reason that we should have to give up our pseudonymity or anonymity in order to share our code with the world.
An individuals anonymity does not take precedence over a professional supply chain that requires transparency, especially in the context of Top-N packages. The Linux kernel is one such example that does not accept anonymous contributions.
> An individuals anonymity does not take precedence over a professional supply chain that requires transparency
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.
The flip side is that individuals don't owe anyone anything. You want to build your "professional supply chain" out of code by individual contributors who just want to share with the world? That's fine, but don't go thinking you can make demands of them just because you wanted to build a business on their good will.
Great for you, I guess there'll be lots of work for you to do if that were to happen.
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.
> I feel like there are still too many hands in this particular cookie jar. MFA or no. On average, how many other organizations & human developers are somehow involved in the dependency graph of a modern node.js project?
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.
The difference is people have become conditioned to trust corporations and organisations, so the software/hardware you mentioned have people or addresses who must answer if they get compromised. Whether they answer is a different thing, and whether this is a good model for everyone is another question. NPM packages on the other hand are dependent on random individuals for integrity and society doesn't trust individuals as much as registered entities, especially profit making ones.
First, yes: there absolutely should be better tools for authors to sign & authenticate their own tools, with heightened cryptographic authentication means. Projects like sigstore get this (and wish to respect privacy![1]). But what's spoken of here is a deep imposition, and doesn't empower authors, but demands of them.
> 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.
Thank you. Ultimately I would agree that some more security is good, that we do we need capabilities & strategies for trust, need to make more options available.
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.
I believe the conquer-all thinking of big corporations is fundamentally incompatible with open-source culture, if there is such a thing. Top-down, authoritarian measures are too much in their DNA, and that includes the CYA angle. I suspect this might end with the usual “Embrace, Extend, Extinguish” — not because someone consciously follows an evil plan, but because of that fundamental incompatibility. It will increasingly be “our way or the highway” and people who disagree will have to make camp somewhere else, if they can. But can they really when NPM practically holds a monopoly position in its space?
> Your desire for a cathedral is incompatible fundamentally & at every level with the bazaar.
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.
Do we need to go this far? Why not just require a DNS which is what all of web security is centered around anyway?
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.
> 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.
this is absolutely dystopian. Please don't give microsoft any more ideas.
> 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.
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.
Sadly, 2FA won't help against malicious developer or a developer selling package to a malicious owner.
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.
At the very least Maven-style DNS-based namespaces would be quite welcome... Then these authentication schemes or even "reputation" becomes DNS based which is much easier to do. Instead of having this random cutoff of popularity.
I don't really get why all these package managers don't copy this from the Java world.
Hi, random developer that somehow ended up in the top 500 but didn't have 2FA turned on (https://www.npmjs.com/package/xlsx)! 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. Assumably the same fate befalls other random devs.
Did they tell your users that they locked out the developers? Uhm.... I kinda of expected some mediation or a step-by-step, but that just a dumpster fire solution.
> 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
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?
>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.
Have they already enforced 2FA? The tool that I built to detect "risky" NPM/PyPI packages [1] still shows expired email domain for browserify (a top NPM package)
Well, it’s probably only enforced if you submit a new version; can’t really disable a top package just because the author hasn’t logged in in a while. browerify was last updated two years ago and probably won’t see a new release ever, so the requirement doesn’t actually matter.
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
This. And this is the problem with signing too, in general.
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.
I'm a top 500 package maintainer apparently (I think for my work on ts-loader but I'm not certain).
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
If you give your otp to a phishing site, it might not login again, but it can retain this session cookie for as long as it's valid and use it for access all that time.
Years ago, when I was less security aware, I shared my password across different accounts. Not wise, but I know better now. One site that I used was hacked and my password compromised. The hacker was able to use that password to gain control of my npm account. Lesson learned.
The rare phishing attack is hardly the danger with NPM. It's the implicit trust you put in some random person on the internet to not mess with your production code. The left-pad debacle was a benign beginning to what is now a full blown existential crisis for the JS community. There is so much incentive out there to compromise a package now, and so many packages, and so little oversight, that it's inevitable.
What happens when a developer can't publish a security update because they don't have 2FA enabled for a popular package? I was almost in this position. I don't have a phone, I don't have 2FA enabled and am not looking to do so. It seems like a 2FA mandate is going to ensure that people lose access to their accounts and won't be able to publish updates at all.
I don't want a yubikey either. Hardware products are notorious for being subverted by agencies, honest companies can be bought by agency shell companies, etc.
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.
You don't need a phone to have multi-factor. You presumably have a PC if you're contributing to a package, so you can use a computer-based OTP generator, like Authy.
Sure, if your computer gets owned, it won't help, but it's still much better than nothing and practically free.
What happens if tomorrow my laptop falls into the pool? Or gets stolen? I know the password of my password manager and my main emails, but for npm with 2FA I would either be:
- 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.
76 comments
[ 3.9 ms ] story [ 154 ms ] threadI 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.
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.
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.
[0] https://news.ycombinator.com/item?id=31575690
From npm.
Does this no longer apply? People can't publish from CI anymore as 2FA is now required?
1. https://github.com/ossillate-inc/packj
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
this ain't gonna do shit about Kony 2022 activism either, which is definitely going to be the next big thing
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.
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.
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?
Get a yubikey[0], that way you don't need a phone.
0. https://www.yubico.com/products/
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.
a move in the right direction
also they should deny new IPs (other than different subnets) until real person verification