Related:<p><a href="https://news.ycombinator.com/item?id=32037562" rel="nofollow">https://news.ycombinator.com/item?id=32037562</a> "Congratulations: We now have opinions on your open source contributions"<p><a href="https://news.ycombinator.com/item?id=32026624" rel="nofollow">https://news.ycombinator.com/item?id=32026624</a> "Atomicwrites' old versions have been purged from PyPI"<p><a href="https://news.ycombinator.com/item?id=32058053" rel="nofollow">https://news.ycombinator.com/item?id=32058053</a> "PyPI is rolling out 2FA for critical projects, giving away 4k security keys"
There's a very simple way to make that opinion count, you can hire the maintainer.<p>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.<p>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.<p>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.
The article touches on an important point: the set of open-source developers includes PyPI maintainers. A related distinction is that yes development effort required matters, but so does operational effort required. By enforcing 2FA, PyPI reduces their support burden a bit by not having to deal with account takeovers, worrying about account takeovers, and responding to account takeovers. Yes, by mandating 2FA that increases the developer's effort, but by refusing to use 2FA that increases the operational effort of PyPI. There's probably a discussion to be had about how much can PyPI lower its level of effort by large amounts by imposing small increases in effort on developers, and whether those effort values are large or small or whatever, but in this particular case I'm inclined to support the small amount of developer effort required to massively reduce the operational effort of both PyPI and everyone responsible for vetting packages for use
> So, look, I get that there are some people who want to live in a world built on caveat emptor and the idea that it’s always and only your fault if something bad happens to you. I get that there are some people who think this is the only kind of world open source can be. Maybe Armin is one of those people, or maybe he just argues like one without realizing or intending it. [...] But no. Just… no. That would be a terrible world, and a terrible model for open source software.<p>Is "that would be a terrible world" supposed to be a counter-argument? The world <i>is</i> 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 <i>should not</i> magically go away), and only adds an undue burden on developers.<p>The internet is a dark forest and I think it would do us a bit of good to treat it as such.
I don't understand why this is up for debate.<p>The Atomicwrites maintainer/author has been using PyPIs servers and infrastructure to host and serve his project for free.<p>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.<p>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 <i>required</i> to take the change - after all they gave it to you for free.
I feel like some of the disconnect comes from being a mandate rather than a persuasive recommendation. Imagine that they included some sort of case study to make it less abstract:<p>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.<p>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".<p>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.
> More seriously: two-factor auth is such a reasonable bare-minimum and easy-to-do (from the account-holder end) thing for account security these days that the objections being raised make no sense to me.<p>As a security engineer, this is the thing I don't get about dissenters. Any account I actually care about has 2FA on it.<p>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.
> And finally: if you’re determined to take something I’ve said above, find the least charitable interpretation of it you can come up with, and argue with that, please know that I don’t read Hacker News and haven’t for years, so I won’t see or respond to you.<p>from the linked article, i'll just leave that here
I keep seeing this claim that open source maintainers shouldn't be upset about a 3rd party mandating we increase our maintenance burden to follow their new rules, because it's all about responsibility.<p>But I also see people claiming that it's not OK for the UK to require an increased maintenance burden for the same reason: <a href="https://news.ycombinator.com/item?id=32055756" rel="nofollow">https://news.ycombinator.com/item?id=32055756</a><p>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.<p>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 <i>big</i> problem.
> If he doesn’t owe us anything, then we also don’t owe him anything. Perhaps he’d like to take back his code and the rest of the world can take back all the opportunities and other things he’s been given In exchange.<p>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.
With the belief that everyone is well intentioned and wants whats best for everyone, I think the thing that freaks me out about this whole thing is that through some process a developer has had their work declared 'critical'. If PyPI said this was a new requirement for everyone, then it would be make more sense, but the sudden declaration just seems problematic. I get there is a resource issue, but no one likes getting an e-mail that they're now subject to new rules not applied to others.<p>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.<p><i>But there’s a reason why the slippery slope is a fallacy</i><p>Yeah, if anything, its a certainty not a fallacy.
writing open-source doesn’t mean people can’t criticize you. It doesn’t mean the places you publish your software can ask you to do stuff or they’ll un-publish. It doesn’t mean others can’t republish them yourself.<p>It <i>does</i> 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.<p>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.<p>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.
Choosing to use FOSS software to build products/services has always involved an element of caveat emptor, and even with the best of intentions, mistakes and errors are introduced sometimes, as they can be into any commercial software.<p>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, ...).<p>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 <i>massively</i> worthwhile, especially when comparing the technology economics of today with years and decades past.<p>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.<p>(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)
I am totally on board with critical packages offering enhanced security to protect the user.<p>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.
With all due respect to James, without whom I probably wouldn't have my current job (I've been programming in Django since the 0.96 days, that is 16 years now), I think Armin is right on this one:<p>> PyPI asks for 2FA today, what might they ask for tomorrow?<p>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.
> Some of this may just be due to incommensurable world-views. My view of the world is based on the idea that my actions may have consequences not only for me, but also for other people, and that I have some responsibility to at least consider those other people when deciding what actions I will take.<p>Very well then. Do whatever you think is necessary and appropriate.<p>For you. Don't heft your ideas on other people.
Well, there's an easy solution to square these viewpoints. People who prefer a caveat emptor can keep operating like that, and people who want to be responsible can drop the "AS IS" clause from the license and put their money where their mouth is. (And really, none of this "well yeah the license says that but really you should be held to account for other stuff"; either commit or don't.)