10 ms·

Yes, I have opinions on your open source contributions

104 points by di 4y ago

jrockway 4y ago
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: 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.
- zmgsabst 4y ago
  I have the feeling that’s because it’s a “best practice” and not a data-driven decision. 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.
- franciscop 4y ago
  That leaves a strange taste in my mouth. I love writing open source for both me and other devs to use it and make their lives easier; I understand that big companies will also use it since that's one of the places where devs work, and since I make mostly tools or meta-tools ("dev solutions" and not "business solutions") I'm happy with this arrangement. When I do a more business-like solution, I tend not to publish it as open source and remain on my list of trying-to-monetize side projects. 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
  - jrockway 4y ago
    With no data, I'm assuming this is all business-driven. Nobody is compromising software supply chains to make your 3D printer print 8% slower for the lulz. They're doing it to hack companies and compromise user data. If open source was just hobbyists making stuff for hobbyists, it might not even require a login to update a package. With companies involved, they to reduce this risk, and this comes at the cost of people not involved with the company's business. I can see why authors get annoyed; they are being required to change their workflow for a use case that doesn't interest them. Being asked to do boring work for free is not a great solution to anything. 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.
    - deleted 4y ago
      [deleted]
    - tsimionescu 4y ago
      > 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. That is just entitlement on the part of some open source devs. PyPI is already providing a huge service for them: it is publishing their package free of charge. Furthermore, it is maintaining old versions, scanning others for vulnerabilities, replicating across the world, resolving dependencies etc. They have every right to ask anyone who is enjoying their completely free service to put in the minute amount of extra work required to set up 2FA. Of course, anyone is also free but to want to put in that work, and so they can stop delivering their package on PyPI. Absolutely your right as an open source maintainer, and you have no one to answer to if that breaks some builds.
- deleted 4y ago
  [deleted]
- tsimionescu 4y ago
  Why are so many arguments acting like the maintainers of PyPI who imposed this change are not themselves open source developers whose time none of us, including those who publish their open source code on PyPI, pay for? 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.
- nemothekid 4y ago
  I don't see why people should be persuaded at all. PyPi is a software distribution mechanism to millions of PC globally. PyPi is putting their footdown and saying we are going to do everything in power to prevent PyPi from being used as a global malware distribution system. That involves not only securing our software, but ensuring the people who have the capability to do damage are following appropriate security protocol. 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.
  - pyrale 4y ago
    > It's the responsible thing to do. 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.
    - samastur 4y ago
      What costs? You can stuff 2FA token generation in many password managers that run on the very computer on which you develop. It costs you exactly zero except a couple of minutes to set it up.
      - pyrale 4y ago
        > You can stuff 2FA token generation in many password managers that run on the very computer on which you develop. That's one of the reasons I believe 2FA is mostly security theater. That and people insisting they need their shitty app on my unsecured phone. It's not two-factor if all of it is running on the same hardware.
        nemothekid 4y ago
        >That's one of the reasons I believe 2FA is mostly security theater It's something you know + something you own. That's 2FA.
- NoGravitas 4y ago
  > 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". 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.
  - jrockway 4y ago
    Yeah, I totally get that. I think that's why some authors just removed their modules.
jwilk 4y ago
Related: https://news.ycombinator.com/item?id=32037562 https://news.ycombinator.com/item?id=32037562 "Congratulations: We now have opinions on your open source contributions" https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624 "Atomicwrites' old versions have been purged from PyPI" https://news.ycombinator.com/item?id=32058053 https://news.ycombinator.com/item?id=32058053 "PyPI is rolling out 2FA for critical projects, giving away 4k security keys"
- adfm 4y ago
  Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?
  - woodruffw 4y ago
    There are many weights involved; PyPI is trying to strike a balance between them. 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.
    - woodruffw 4y ago
      I forgot to mention another weight: maintainer time. A universal 2FA mandate would drastically increase the amount of support time maintainers spend helping users recover their accounts (a perverse problem to have!).
yjftsjthsd-h 4y ago
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.)
vore 4y ago
> 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. 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.
- TimPC 4y ago
  I feel like you’re taking the author out of context. His point is that without the open-source work fewer opportunities would exist for the person doing it. So it’s a bit disingenuous to act like you do all of this “purely for free” when it’s more like “self-marketing”. I get how imposing on people doing the former can be unreasonable, but asking things of people doing the later seems quite fair.
  - ConstantVigil 4y ago
    [flagged]
    - TimPC 4y ago
      The original author seemed to think so and the regular speaking engagements and book deals seem consistent with that. It might not be the exclusive reason but it certainly seems a factor.
      - ConstantVigil 4y ago
- skybrian 4y ago
  Yeah, the second sentence isn't a great argument because it's a voluntary relationship, you can quit at any time, and that doesn't mean you have to give back any benefits you received. 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.
paganel 4y ago
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: > 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.
- kevinh 4y ago
  How does mandating 2FA get them any closer to that second point? If they wanted to start with that, they could. They're two separate issues.
  - bjt2n3904 4y ago
    The entirety of the last decade in open source software development can be summarized as this: it is morally reprehensible for your project to not support the causes du jour. 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.
    - kevinh 4y ago
      If the last decade has been all about that, then clearly a 2FA mandate won't lead to it, since it's already here. FWIW, I have multiple open source projects. I don't have a COC. I haven't renamed any of my branches. I haven't gotten any pushback.
mushufasa 4y ago
> 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. from the linked article, i'll just leave that here
- ConstantVigil 4y ago
clysm 4y ago
> 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. 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.
- atoav 4y ago
  Well it depends, is the thing the second factor is meant to protect actually worthy of that level protection?
  - elteto 4y ago
    Well, they literally thought about this! It's only required for critical packages, for whatever definition of critical they have.
- omoikane 4y ago
  Depends. Some websites insists on implementing 2FA in a poor way (e.g. installing dodgy custom apps on users' phones), so for accounts that users really care about, it might be the case that they would avoid these poor implementations to reduce attack surface. (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)
bjt2n3904 4y ago
> 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. Very well then. Do whatever you think is necessary and appropriate. For you. Don't heft your ideas on other people.
dvt 4y ago
> 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. 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.
- sam0x17 4y ago
  > 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. 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.
pyrale 4y ago
There's a very simple way to make that opinion count, you can hire the maintainer. 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.
- heavyset_go 4y ago
  Agree with this, and you've put it better than I would've.
- rsync 4y ago
  "There's a very simple way to make that opinion count, you can hire the maintainer." 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.
ranger207 4y ago
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
- jka 4y ago
  That's a very good point regarding operational cost of handling account takeovers. 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.
- anothernewdude 4y ago
  You still need to deal with account takeovers.
  - GauntletWizard 4y ago
    You need to deal with them a lot less. Not zero, but I would be surprised if account takeovers weren't 99% defanged by this move.
armchairhacker 4y ago
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. 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.
ConstantVigil 4y ago
jka 4y ago
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. 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)
- tsimionescu 4y ago
  What does business have to do with PyPI? They are themselves a free project, for everyone using them.
  - jka 4y ago
    Offering an opinion: the tech industry is invested in the success of PyPI -- perhaps not always in a literal monetary sense, you're right, but certainly in an ecosystem sense.
jph00 4y ago
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. 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 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.
- tsimionescu 4y ago
  > 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.
  - jph00 4y ago
    Perhaps -- but not "definitely". It depends on what the frequency of each of those things 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).
    - donaldstufft 4y ago
      - https://python-security.readthedocs.io/pypi-vuln/index-2022-05-24-ctx-domain-takeover.html https://python-security.readthedocs.io/pypi-vuln/index-2022-... - https://www.mend.io/resources/blog/npm-package-javascript-library-compromised-via-account-takeover/ https://www.mend.io/resources/blog/npm-package-javascript-li...
olliej 4y ago
I don't understand why this is up for debate. 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.
- ivraatiems 4y ago
  > 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.
  - olliej 4y ago
    The atomic writes maintainer was free to simply stop using their hosting service, but what he did was try to continue to use their hosting service without doing the bare minimum to protect that service. 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.
    - the_mitsuhiko 4y ago
khlpq 4y ago
protomyth 4y ago
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. 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.
- giaour 4y ago
  The "critical" designation is not arbitrary. It's based on download statistics. From https://pypi.org/security-key-giveaway/ https://pypi.org/security-key-giveaway/: > 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.
  - protomyth 4y ago
    Its still not a great measure. A project with three downloads that are all from the credit rating agencies, or a project with 100 downloads from all banks would be considered 'critical' by most folks.
    - giaour 4y ago
      But not by PyPI! Whoever is in charge of supply chain security at those credit rating agencies and banks should think long and hard about what they've gotten themselves into, though.
anothernewdude 4y ago
Number of downloads probably does correlate with criticality. But I don't imagine it does that well.
- woodruffw 4y ago
  Number of downloads correlates strongly with "centrality," i.e. how highly connected (in the dependency graph) a package is to other packages. That, in turn, maps pretty well to "criticality," if your definition of "critical" is "a malicious takeover of this package would compromise large swaths of the Python ecosystem."
tpoacher 4y ago
I am totally on board with critical packages offering enhanced security to protect the user. 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.

104 points by di 4y ago

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: 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.

zmgsabst 4y ago
I have the feeling that’s because it’s a “best practice” and not a data-driven decision. 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.
franciscop 4y ago
That leaves a strange taste in my mouth. I love writing open source for both me and other devs to use it and make their lives easier; I understand that big companies will also use it since that's one of the places where devs work, and since I make mostly tools or meta-tools ("dev solutions" and not "business solutions") I'm happy with this arrangement. When I do a more business-like solution, I tend not to publish it as open source and remain on my list of trying-to-monetize side projects. 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
- jrockway 4y ago
  With no data, I'm assuming this is all business-driven. Nobody is compromising software supply chains to make your 3D printer print 8% slower for the lulz. They're doing it to hack companies and compromise user data. If open source was just hobbyists making stuff for hobbyists, it might not even require a login to update a package. With companies involved, they to reduce this risk, and this comes at the cost of people not involved with the company's business. I can see why authors get annoyed; they are being required to change their workflow for a use case that doesn't interest them. Being asked to do boring work for free is not a great solution to anything. 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.
  - deleted 4y ago
    [deleted]
  - tsimionescu 4y ago
    > 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. That is just entitlement on the part of some open source devs. PyPI is already providing a huge service for them: it is publishing their package free of charge. Furthermore, it is maintaining old versions, scanning others for vulnerabilities, replicating across the world, resolving dependencies etc. They have every right to ask anyone who is enjoying their completely free service to put in the minute amount of extra work required to set up 2FA. Of course, anyone is also free but to want to put in that work, and so they can stop delivering their package on PyPI. Absolutely your right as an open source maintainer, and you have no one to answer to if that breaks some builds.
deleted 4y ago
[deleted]
tsimionescu 4y ago
Why are so many arguments acting like the maintainers of PyPI who imposed this change are not themselves open source developers whose time none of us, including those who publish their open source code on PyPI, pay for? 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.
nemothekid 4y ago
I don't see why people should be persuaded at all. PyPi is a software distribution mechanism to millions of PC globally. PyPi is putting their footdown and saying we are going to do everything in power to prevent PyPi from being used as a global malware distribution system. That involves not only securing our software, but ensuring the people who have the capability to do damage are following appropriate security protocol. 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.
- pyrale 4y ago
  > It's the responsible thing to do. 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.
  - samastur 4y ago
    What costs? You can stuff 2FA token generation in many password managers that run on the very computer on which you develop. It costs you exactly zero except a couple of minutes to set it up.
    - pyrale 4y ago
      > You can stuff 2FA token generation in many password managers that run on the very computer on which you develop. That's one of the reasons I believe 2FA is mostly security theater. That and people insisting they need their shitty app on my unsecured phone. It's not two-factor if all of it is running on the same hardware.
      - nemothekid 4y ago
        >That's one of the reasons I believe 2FA is mostly security theater It's something you know + something you own. That's 2FA.
NoGravitas 4y ago
> 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". 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.
- jrockway 4y ago
  Yeah, I totally get that. I think that's why some authors just removed their modules.

jwilk 4y ago

Related: https://news.ycombinator.com/item?id=32037562 https://news.ycombinator.com/item?id=32037562 "Congratulations: We now have opinions on your open source contributions" https://news.ycombinator.com/item?id=32026624 https://news.ycombinator.com/item?id=32026624 "Atomicwrites' old versions have been purged from PyPI" https://news.ycombinator.com/item?id=32058053 https://news.ycombinator.com/item?id=32058053 "PyPI is rolling out 2FA for critical projects, giving away 4k security keys"

adfm 4y ago
Seems a bit janky to only require 2FA from “critical projects” and not all projects. Why cut corners?
- woodruffw 4y ago
  There are many weights involved; PyPI is trying to strike a balance between them. 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.
  - woodruffw 4y ago
    I forgot to mention another weight: maintainer time. A universal 2FA mandate would drastically increase the amount of support time maintainers spend helping users recover their accounts (a perverse problem to have!).

yjftsjthsd-h 4y ago

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.)

vore 4y ago

> 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. 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.

TimPC 4y ago
I feel like you’re taking the author out of context. His point is that without the open-source work fewer opportunities would exist for the person doing it. So it’s a bit disingenuous to act like you do all of this “purely for free” when it’s more like “self-marketing”. I get how imposing on people doing the former can be unreasonable, but asking things of people doing the later seems quite fair.
- ConstantVigil 4y ago
  [flagged]
  - TimPC 4y ago
    The original author seemed to think so and the regular speaking engagements and book deals seem consistent with that. It might not be the exclusive reason but it certainly seems a factor.
    - ConstantVigil 4y ago
skybrian 4y ago
Yeah, the second sentence isn't a great argument because it's a voluntary relationship, you can quit at any time, and that doesn't mean you have to give back any benefits you received. 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.

paganel 4y ago

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: > 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.

kevinh 4y ago
How does mandating 2FA get them any closer to that second point? If they wanted to start with that, they could. They're two separate issues.
- bjt2n3904 4y ago
  The entirety of the last decade in open source software development can be summarized as this: it is morally reprehensible for your project to not support the causes du jour. 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.
  - kevinh 4y ago
    If the last decade has been all about that, then clearly a 2FA mandate won't lead to it, since it's already here. FWIW, I have multiple open source projects. I don't have a COC. I haven't renamed any of my branches. I haven't gotten any pushback.

mushufasa 4y ago

> 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. from the linked article, i'll just leave that here

ConstantVigil 4y ago

clysm 4y ago

> 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. 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.

atoav 4y ago
Well it depends, is the thing the second factor is meant to protect actually worthy of that level protection?
- elteto 4y ago
  Well, they literally thought about this! It's only required for critical packages, for whatever definition of critical they have.
omoikane 4y ago
Depends. Some websites insists on implementing 2FA in a poor way (e.g. installing dodgy custom apps on users' phones), so for accounts that users really care about, it might be the case that they would avoid these poor implementations to reduce attack surface. (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)

bjt2n3904 4y ago

> 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. Very well then. Do whatever you think is necessary and appropriate. For you. Don't heft your ideas on other people.

dvt 4y ago

> 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. 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.

sam0x17 4y ago
> 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. 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.

pyrale 4y ago

There's a very simple way to make that opinion count, you can hire the maintainer. 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.

heavyset_go 4y ago
Agree with this, and you've put it better than I would've.
rsync 4y ago
"There's a very simple way to make that opinion count, you can hire the maintainer." 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.

ranger207 4y ago

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

jka 4y ago
That's a very good point regarding operational cost of handling account takeovers. 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.
anothernewdude 4y ago
You still need to deal with account takeovers.
- GauntletWizard 4y ago
  You need to deal with them a lot less. Not zero, but I would be surprised if account takeovers weren't 99% defanged by this move.

armchairhacker 4y ago

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. 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.

ConstantVigil 4y ago

jka 4y ago

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. 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)

tsimionescu 4y ago
What does business have to do with PyPI? They are themselves a free project, for everyone using them.
- jka 4y ago
  Offering an opinion: the tech industry is invested in the success of PyPI -- perhaps not always in a literal monetary sense, you're right, but certainly in an ecosystem sense.

jph00 4y ago

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. 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 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.

tsimionescu 4y ago
> 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.
- jph00 4y ago
  Perhaps -- but not "definitely". It depends on what the frequency of each of those things 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).
  - donaldstufft 4y ago
    - https://python-security.readthedocs.io/pypi-vuln/index-2022-05-24-ctx-domain-takeover.html https://python-security.readthedocs.io/pypi-vuln/index-2022-... - https://www.mend.io/resources/blog/npm-package-javascript-library-compromised-via-account-takeover/ https://www.mend.io/resources/blog/npm-package-javascript-li...

olliej 4y ago

I don't understand why this is up for debate. 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.

ivraatiems 4y ago
> 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.
- olliej 4y ago
  The atomic writes maintainer was free to simply stop using their hosting service, but what he did was try to continue to use their hosting service without doing the bare minimum to protect that service. 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.
  - the_mitsuhiko 4y ago

khlpq 4y ago

protomyth 4y ago

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. 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.

giaour 4y ago
The "critical" designation is not arbitrary. It's based on download statistics. From https://pypi.org/security-key-giveaway/ https://pypi.org/security-key-giveaway/: > 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.
- protomyth 4y ago
  Its still not a great measure. A project with three downloads that are all from the credit rating agencies, or a project with 100 downloads from all banks would be considered 'critical' by most folks.
  - giaour 4y ago
    But not by PyPI! Whoever is in charge of supply chain security at those credit rating agencies and banks should think long and hard about what they've gotten themselves into, though.

anothernewdude 4y ago

Number of downloads probably does correlate with criticality. But I don't imagine it does that well.

woodruffw 4y ago
Number of downloads correlates strongly with "centrality," i.e. how highly connected (in the dependency graph) a package is to other packages. That, in turn, maps pretty well to "criticality," if your definition of "critical" is "a malicious takeover of this package would compromise large swaths of the Python ecosystem."

tpoacher 4y ago

I am totally on board with critical packages offering enhanced security to protect the user. 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.