Company C uses database driver P. On 2020-01-02 they upgraded their app to the latest version. On 2020-01-04 they noticed that someone stole all their user data. Upon investigation, Package P had a version uploaded on 2019-12-24 that sends all user data to evil.example.com. The tooling to upgrade the package doesn't show diffs, so company C had no way to detect this malicious change. How did such a compromised version get uploaded? Looking at the audit logs, it appeared that there were 2398438 unsuccessful login attempts to package P author's account, before finally uploading the new patch release from the same IP. Company C lost 8 billion dollars as a result of this. If author A had used multi-factor authentication, then this wouldn't have happened, because it would have taken more login attempts than there are atoms in the Universe.
Then the author can see "hey I can save the shareholders of some random corporation 8 billion dollars if I make it harder for myself to release software". That's a better incentive than "because I told you to".
I know it sounds a bit disingenuous to say this is just for the shareholders of random corporations. I'm being a little snarky. It's also good for your reputation to not get hacked, and using 2FA to log in every time is probably less time overall than reacting to a single compromise. Imagine how many emails you're going to get. Big pain. I just think it's important to show authors the cost/benefit. 2FA is easy. Next time it might not be something that's as easy, though.
But if you quantify it like this, "this company saved 8 billion dollars out of some extra work on your side, here is a pat in the back because they'd never even consider give back a single cent or helping in any way" it feels a bit strange. I know it's on me, and I just learned this contradictory feeling so need to unravel/understand it, but you def got the opposite feeling from me as expected.
Edit: you added the "I know it sounds a bit disingenuous to say this is just for the shareholders of random corporations." later, right? Which kinda reflects a bit of this feeling
When I write open source software I'm not doing it for Bezos. I'm doing it for Heather down the street who is trying to get a cool little project off the ground and maybe pay some bills. I'm even writing it for Frank who runs a modest 20 person dev shop and maybe contributes back a bit here or there where they find the warts.
I'm not building it for the psychos that have lost all touch with humanity.
Personally, I don't have a horse in this game. I always use 2FA when it's available. I have already made the necessary adjustments in my workflow. But I get why people are annoyed that they have to change something. Imagine that this was "we'll send you a check for $1000 if you enable 2FA on your account". Bet there would have been zero angry blog posts.
PyPI asking for 2FA is in no way different from an open source project asking you to run their unit tests before submitting a PR. Sure, it puts a burden on you, the open source contributor, but it is balanced by removing a burden from the project maintainers.
It's the responsible thing to do. If a package gets compromised its PyPi that has to do cleanup work. It's like complaining that the government forces you to wear your seatbelt.
Also, conveniently, it's the thing whose cost is not paid by the people deciding to enforce it.
> If a package gets compromised its PyPi that has to do cleanup work.
Yeah, that's the very essence of being a distribution tool.
To be quite honest, I would rather the shareholders of some random corporation do lose 8 billion dollars. In fact, I would be willing to pay a small amount to see it.
Wouldn’t they have led with, “we’ve witnessed X attempts and Y takeovers in the past year, so we’re introducing new security measures aimed at…”
To me, this seems like more frog-boiling authoritarianism “for our own good”, like the COVID lockdowns, censorship, etc.
I’m tired of technology forcing me to do things “for my own good” — and I recommend against companies who engage in those policies.
These are all the same arguments trotted out to justify Windows spyware and forced updates that routinely lag my computer for hours — because Microsoft knows better than me how to use my desktop and isn’t shy about pushing me out of the way to do so.
> PyPI asks for 2FA today, what might they ask for tomorrow?
Yes, slippery slopes are real because they happen, especially in this very tense and very non-rational geo-political climate. Yes, today it might just be "use 2FA with you still want to actively maintain your own package", tomorrow it might be "boo-hoo-hoo, you've followed/liked Putin/Xi/whoever the powers that be don't like, you're a threat to liberal democracy, we can't leave critical infrastructure in your hands, bye-bye", and there will be nothing for the package maintainer left to do at that point.
> And if your package gets established and has people regularly using it, you have some responsibility not to mess with those users. If you want to make backwards-incompatible changes, for example, communicate them and bump the major version number. If you want to stop maintaining the package, post an announcement about it and be willing to hand over to someone else to continue work.
If and when they start policing political views of their maintainers, it would be fair to criticize them. But the theoretical possibility of such a thing happening has no relevance to whether 2FA is a reasonable request.
You must adopt a COC. You must rename your branch from "master" to "main". You must use "inclusive" language in your documentation.
Why? Because you must assume the responsibility for everything your project touches. A bad person uses your leftpad.js to perpetuate badness. You must stop them. Someone might get their feelings hurt. You must preemptively protect them.
This is an impossible task. 2FA is fine, sure. I use it myself, and advocate for others to do so as well.
But I'm sick and tired of the "harm reduction" mantra that means I have to entirely rewrite my documentation every 6 months.
Look, publishing to PyPI is not a right. If typing 6 digits is too much burden you can drop a source tarball in some web page and call it a day, you don't have to go through PyPI. Done.
I, for one, I'm very very glad that a piece of _critical infrastructure_ that I depend on is a bit more secure.
The 2FA thingie is not implemented because of some random dude who might want to steal a bitcoin or two, is implemented against state actors. This being the US we're talking about (and the West more generally) the state actors taken into consideration are: China, Russia, Iran, probably North Korea (probably in this order). Hence my mention of China and Russia in my initial comment.
Is "that would be a terrible world" supposed to be a counter-argument? The world is built on caveat emptor, especially when downloading random packages off the internet. That's why browsers are sandboxed. That's why people run virtual machines. The vetting process for adding new dependencies at big corporations can literally last months. The 2FA nonsense does basically nothing in practice (vetting will not and should not magically go away), and only adds an undue burden on developers.
The internet is a dark forest and I think it would do us a bit of good to treat it as such.
This is true, but to play devil's advocate, how many HN articles have we seen where X critical NPM package had been compromised by a malicious user who gained control of the package maintainer's account? There are many examples of this. If a new package deployment system were to launch in 2022, I wouldn't be surprised if 2FA was required for all publicly listed packages, full stop, not just critical ones. Viewed through that lens, it really isn't that unreasonable.
That said, I think full power should be in the hands of the developers who maintain these packages when it comes to the actual content of the packages. Package systems should not be editorializing. If the author of [insert major package here] wants to upgrade a version that replaces the whole package with a console animation of a turtle, that's his/her choice as a developer, and simply should be viewed as a "breaking change". Intervening in THOSE scenarios I view as completely out of control on the part of package ecosystems. Let people leverage their creations however they like. Your trust is supposed to be in the maintainer. If they aren't trustworthy, you shouldn't use their software in the first place. If they decide to go in a new, breaking direction, that's their decision. Caveat emptor.
These scenarios though, are starkly different from scenarios where the package maintainer's own intent is subverted by a malicious hacker / user. That's a whole other can of worms, and I agree we need better controls to protect all packages from these types of scenarios.
For instance, PyPI will take down your software if we determine it to be malicious in some way, which is extending editorial control over what's on PyPI.
Generally speaking, though, PyPI does not concern itself with the contents of the packages shipped through it as long as they are reasonable packages. If a project wants to break compatibility, then that's on them. We strive to let projects manage themselves, in whatever way they think makes the most sense.
I don't understand this claim -- are you saying that 2FA adds no protection of value in the context of package maintainership, or that does nothing in general? I'd like to understand the reasoning behind either, whichever it is.
My 0.02c is that 2FA has empirically reduced the incidence of ATOs on major services, and eliminates entire systemic weaknesses in account systems (like ATO via password reset). It stands to reason (to me) that PyPI is a service like all others, and benefits similarly.
1. Doesn't protect against the developer actually being malicious
2. Is able to be broken, especially when both factors occur on the same mobile device.
3. Doesn't do anything to prevent the theft of API keys from CI/CD builds.
I'm trying to say two things: (1) that 2FA adds little, if any, protection of value in the context of package maintainership. In other words, if someone wants to be a malicious actor (say, they had a "legitimate" package from versions 1.0 to 2.1, but 2.2 contains a trojan), they can do it even with 2FA. And (2), it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with. If you're 15 or 16 years old, excited to finally get your package on PyPI, but all of a sudden, you have to jump through all these hoops, including doxxing yourself and providing a real phone number, you would 100% be deterred.
https://news.ycombinator.com/item?id=32037562 "Congratulations: We now have opinions on your open source contributions"
https://news.ycombinator.com/item?id=32026624 "Atomicwrites' old versions have been purged from PyPI"
https://news.ycombinator.com/item?id=32058053 "PyPI is rolling out 2FA for critical projects, giving away 4k security keys"
Among them:
* Project installs follow a power law distribution: the top 1% of packages account for 99% of installations, and the remaining 99% account for roughly 1% of installations. In other words: prioritizing the security of the 1% of packagers means prioritizing the 99% of users who depend on those critical projects.
* PyPI has tried really hard to make 2FA as effortless and non-invasive as possible: the current program includes giving away two free physical hardware tokens, as well as a long grace period to ensure that maintainers are not caught in a sudden lurch between their open source and professional obligations. Both of these don't work at scale: PyPI doesn't have the material resources to give every maintainer free hardware tokens, and the same packaging power law means that a large number of relatively inactive maintainers will be caught by any deadline that gets set.
Ultimately, the goal is to maximize the number of users protected, maximize the quality of protection, prevent package user disruption, and minimize maintainer disruption. The current scheme, in my view, does a good job at achieving all of these goals.
FD: I worked on PyPI's 2FA implementation, but I do not represent PyPI and am not a maintainer.
I mean, node-ipc would have happened regardless of how many authentication factors were involved in uploading. And offers to buy ownership will keep coming. What happened to Sourceforge wasn't lack of security.
Turns out those distribution people did more than just wrap software in other formats. Turns out that multi stakeholder thing had merit. Who would have thought?
Agreed.
I don't know if these projects need 2FA "protection" or not - but I'm quite certain that the risk to any particular user is identical whether they are downloading a popular vs. unpopular package.
Total, global risk is, of course, higher for popular packages, but any individual user does not care if their intrusion vector was a popular vs. unpopular package ...
Open source has been built on an endless stream of people making personal sacrifices and often burning out. Seeing friends slowly getting devoured by anxiety crisis or burying themselves to support commercially used software, barely being thanked for what they give to the community, has been one of the most depressing parts of this industry.
If you don't support that particular piece of infrastructure, your opinions on it are worth zero. Even if you're a well-known open source maintainer, and some times even more so. It is understandable that people getting a comfortable job thanks to their contribution on a high-profile project have a different view from people that don't, but that doesn't make it a better view.
In retrospective, open source was bound to have these dynamics, with some people benefiting from their open-source work not seeing why people not paid to participate don't enjoy being told what to do. I wonder whether we'll see a friendlier environment in the future, or whether open-source will end up being a cooperative of companies sharing code among themselves.
I want to describe to you that this is very difficult - almost impossible.
A long time ago I decided that I did, in fact, want my opinions on open source and free software to have more weight than a typical non-contributor and I have made dozens of valid, reasonable - even generous - offers to individuals and projects to advance certain design goals or feature requests - or even simple bug fixes.
It's not that these offers (contract offers, bounties, straight up cash payments, sponsorship, etc.) were rejected - they are typically outright ignored. As in, radio silence. No response whatsoever. I know they got my message and I know they are ignoring it.
I have some pop-psych / cultural analysis / personal anecdata as to why this is (almost always) the case ... I think you can easily sketch a caricature of someone who does something out of love or passion or as a personal challenge but has no way to connect that to expectations or deadlines, or any other personal involvement whatsoever.
But whatever the explanation, be aware that your suggestion is not the magic bullet you think it is.
In particular, it was bound to have those dynamics once the radical possibilities of the Free Software movement were recuperated by capitalism in the form of Open Source.
I'm not sure I have much useful commentary to add, but it does occur to me that a sufficiently-sized pool of software users could inspect changes (either at individual-commit-time and/or at tagged-release-time) regardless of whether each changeset is by the same author or in fact a different person every time.
As a security engineer, this is the thing I don't get about dissenters. Any account I actually care about has 2FA on it.
By today's security standards, NOT adding 2FA just means you don't really care about your project. Hand it over to someone else in that case.
(I am sure it doesn't apply to PyPI, but I am just saying both site operators and users need to adopt best practices in terms of 2FA)
The Atomicwrites maintainer/author has been using PyPIs servers and infrastructure to host and serve his project for free.
PyPI have no responsibility to do that, and that maintainer has always been free to publish his project himself. Instead the Atomicwrites maintainer doesn't want to do that, what they want is to be able to exploit someone else's infrastructure, and they want free rein on that infrastructure despite, again not paying a cent for that infrastructure. There is a weird belief that PyPI is the side of this equation that is exploiting the maintainer - by requiring literally the bare minimum of modern security - and not the Atomicwrites author exploiting the PyPI infrastructure to host their project.
Anyone arguing that PyPI is not allowed to make any demands of someone using their infrastructure, for free, because that is somehow unreasonable, is delusional. It's no different than having your own project, and someone push a PR, and you being required to take the change - after all they gave it to you for free.
He's not arguing they're not allowed. He admits they are allowed, but he doesn't want them to do it. He thinks it's a bad idea.
I don't agree with him, but I think you are misrepresenting his views here.
So I don't believe I am misrepresenting them, nor the people who have defended their actions. They have made it _very_ clear that they believe PyPI should be forced to host every project whether they want to follow the rules or not.
But I also see people claiming that it's not OK for the UK to require an increased maintenance burden for the same reason: https://news.ycombinator.com/item?id=32055756
I think we need to accept that it's not a simple matter of responsibility. It's a question of how much maintenance burden is OK to mandate. The claim that open source maintainers should be fine with this increased burden because "responsibility" is not logically sound.
Also, the idea that there's no problem, because OS maintainers can just remove their package from pypi, totally ignores the point that that would be a really bad outcome for everyone that uses that package. I this that's actually a pretty big problem.
Is definitely not as big a problem as someone taking over their account and publishing malware under their name is.
So far IIUC the frequency of critical projects being removed from pypi is 1 (in the space of a few days - although it came back), and account takeover of critical projects for malware publishing is 0 (in the space of many years).
I feel like this is a rather silly take. Book-writing, speaking, etc opportunities are not ongoing burdens like open source maintainership. Even job opportunities you can choose to quit. I think ultimately if people are doing things for free you can't ask too much of them since they are well within their right to stop doing it for any capricious reason.
In particular, you can quit maintaining an open source package, or stop publishing it in an index and let someone fork it. (Maybe you feel a little guilty, but that seems like a feeling to get over if it's not working out for you.)
But it still works both ways. If you're not finding it fun anymore, that doesn't say anything in itself about who, if anyone, is to blame.
So you maintain a package 'X', that has been determined to be 'critical'. It just seems like some user of package 'X' needs to perform some action to insure the group safety. It just seems like the one party that benefits the most isn't doing anything to help the situation. Thinking about it, what if the three users of your package are the credit agencies? The whole criteria seems a bit arbitrary.
But there’s a reason why the slippery slope is a fallacy
Yeah, if anything, its a certainty not a fallacy.
> What determines if a project is a critical project?
> PyPI determines eligibility based on download counts derived from PyPI's public dataset of download statistics. Any project in the top 1% of downloads over the prior 6 months is designated as critical.
The technology industry (as the typical consumer of FOSS) generally understands that and introduces appropriate measures (dependency reviews, hiring developers with relevant experience, requesting professional security audits, keeping backups, ...).
Despite all those (sometimes expensive) measures, industry continues to develop (and indeed thrive) using FOSS, implying the trade-off is worthwhile. My guess is that it is in fact massively worthwhile, especially when comparing the technology economics of today with years and decades past.
Therefore I think it's reasonable to ask questions any time that barriers are raised -- however small -- on the production-side of FOSS. That's not where the bulk of the revenues are accruing.
(I also have a vague sense that 2FA could later be misused as an attempt to strongly-attribute blame, which again feels potentially unfair/unbalanced. if your business risk is high when upgrading packages, then you should review those updates more carefully and keep a record of the financial efforts and rewards)
from the linked article, i'll just leave that here
It does mean you can ignore any and all criticism and do whatever you want. It does mean you can refuse to do what the package managers or community want. Even if your product has a glaring bug or security hole or is offensive! And you can put the burden of maintaining or patching your app to others.
And that’s fine, if you do so you’re not a bad person. Because others can maintain and patch your app. You have absolutely no obligation to maintain or address any complaints about your open source software.
But you do have to accept that people will make those demands and complaints. Not outright insults and hate speech, those are too far, but complaints about your software (even if harsh) are fine and expected. If they bother you, IMO the best thing to do is politely ask “please stop” and ignore them.
But, I am deeply disturbed about the fact that we've reached this point where "enhanced_security === 2FA" by default (which I hate with a passion), with no alternatives considered.
Very well then. Do whatever you think is necessary and appropriate.
For you. Don't heft your ideas on other people.
