5 ms·

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

• 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.
  • jka 4y ago
    Odd but serious question: could there be ways to distribute versioned software that doesn't require management of developer accounts (and the associated time-and-effort costs related to account takeovers)?
    • tsimionescu 4y ago
      Not if the goal is to avoid vetting each new version as if it were a completely new dependency. The whole reason for the current system, and the very idea of new versions of "the same software", is that we want to be able to rely on the reputation of a project to make certain decisions. For example, we trust Linux 5.11.1 to be non-malicious and to be mostly stable etc largely on the reputation of the Linux project. We don't go around vetting the code of such s project except in efemer specific niches. If we don't trust the provenance of the code we're getting though, that reputation becomes irrelevant. As such, this is a problem of identity assurances and access management, it can't be solved otherwise.
      • jka 4y ago
        Ok: you've provided two requirements that I agree with: - It should be possible to compare between two releases (I'd personally like to see a code diff, ideally with a complete path of the commits involved) - Providing a reputation visibility mechanism (for publishers? author(s)?) across a series of releases is important Those don't require user accounts necessarily, though. And responding to the end of your message: identity assurances, yep, those seem necessary; access management, I'm not so sure.
        • ecnahc515 4y ago
          Access management is required to have identity assurances. If there's no way to ensure someone's identity is secure, how do we know it's them in the first place?
  • donaldstufft 4y ago
    All major repositories editorialize to some extent, they would be awful if they did not. 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.
• woodruffw 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. 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.
  • dvt 4y ago
    > 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'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.
    • woodruffw 4y ago
      > 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. That's a different threat model. We're talking about account takeover, which is a separate risk from maintainers going rogue. 2FA addresses the former; the latter is difficult to address in the general case. Nevertheless, it's something that people are tackling both with static analysis and "reputational" schemes. > it adds an undue burden developers, particularly brand new ones that just want to "publish their package," have to deal with You're right, which is why it's not mandatory for everyday users. The decision to enable 2FA for "critical" packages is a practical and calculated one: most critical packages are maintained not by brand new PyPI users, but by seasoned engineers who understand their centrality to the ecosystem and the importance of measures that secure their work. There's no current plan to make 2FA mandatory for every single user; the threat model doesn't justify it. > including doxxing yourself and providing a real phone number, you would 100% be deterred. I'm not sure what this has to do with PyPI. PyPI does not and has never supported SMS 2FA. This was an intentional design decision on my part. The only supported 2FA methods are TOTP and WebAuthn, both of which can (and do, by default) preserve nominal anonymity. No phone numbers are involved.