3 ms·

You can already (and since a while ago) verify GPG signatures when installing Python packages. Nobody does that. The biggest problem the author didn't really r

You can already (and since a while ago) verify GPG signatures when installing Python packages. Nobody does that. The biggest problem the author didn't really relate to is that most Python packages come with no signature what so ever. So, what are you going to do about those packages if you wanted to verify the rest? -- just verify those that have signatures, and leave those without signatures alone? -- That just sounds ridiculous... By and large, PyPI is the same story we had with HTML: incompetence that breeds more incompetence. The same way how Web browsers encouraged crappy Web developers to generate ever more broken HTML by "helpfully" fixing the broken parts, PyPI by not enforcing the good practices created a community of people who now don't even understand what the problem is. Fighting this is hopeless, because security is by far not the biggest reason why people download and use Python packages. So, even if security sucks, the users, who, ultimately should've been the ones responsible for their security won't do squat. Instead, maybe, at best, there'll be some broken / partial solution from PyPI.

donaldstufft 3y ago
gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secure system on top of it. They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.
- crabbone 3y ago
  Come on. On what planet are you living? What other signing options are the best practices? Hint: "best" doesn't mean "ideal", it simply means "better than anything else".
  - donaldstufft 3y ago
    Also, minisign, signify, sigstore are all much better than gpg for the problem of signing packages.
  - growse 3y ago
    Following "Best practice" is doing what everyone else does, just because everyone else is doing it. "Best practice" is cargo culting. Everyone's got different requirements and constraints. If one thing is apparent, it's that pypi doesn't have in a requirement that packages are signed, because no-one (publishers and clients) is currently using them properly. And yet, python (and pypi) is alive and popular. If that's the case, the "best" package signature scheme is none at all.
  - donaldstufft 3y ago
    GPG/PGP is worse than nothing, because it provides an illusion of security in the majority of use cases unless you build significant infrastructure around it to the point that you're really just using it for access to it's crypto primitives. GPG's Web of Trust cannot answer the question of who is trusted to sign for a particular package on PyPI. At best it can tell you that a key that is signed by someone whose key you've signed. That is not a meaningful security control. Practically nobody is signing GPG keys thinking "would I trust this person to sign for every package I might ever want to download" and they are instead at most trying to verify the identify on the key matches. It's existence creates a bunch of people who insist in trying to take up the oxygen in the room anytime serious security design is trying to happen to try and shoehorn gpg in places where it has no business being.
  - morelisp 3y ago
    Besides the actual tools mentioned, TOFU works basically as well as signatures. Just that already generates a noisy-enough false positive rate.

donaldstufft 3y ago

gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secure system on top of it. They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.

crabbone 3y ago
Come on. On what planet are you living? What other signing options are the best practices? Hint: "best" doesn't mean "ideal", it simply means "better than anything else".
- donaldstufft 3y ago
  Also, minisign, signify, sigstore are all much better than gpg for the problem of signing packages.
- growse 3y ago
  Following "Best practice" is doing what everyone else does, just because everyone else is doing it. "Best practice" is cargo culting. Everyone's got different requirements and constraints. If one thing is apparent, it's that pypi doesn't have in a requirement that packages are signed, because no-one (publishers and clients) is currently using them properly. And yet, python (and pypi) is alive and popular. If that's the case, the "best" package signature scheme is none at all.
- donaldstufft 3y ago
  GPG/PGP is worse than nothing, because it provides an illusion of security in the majority of use cases unless you build significant infrastructure around it to the point that you're really just using it for access to it's crypto primitives. GPG's Web of Trust cannot answer the question of who is trusted to sign for a particular package on PyPI. At best it can tell you that a key that is signed by someone whose key you've signed. That is not a meaningful security control. Practically nobody is signing GPG keys thinking "would I trust this person to sign for every package I might ever want to download" and they are instead at most trying to verify the identify on the key matches. It's existence creates a bunch of people who insist in trying to take up the oxygen in the room anytime serious security design is trying to happen to try and shoehorn gpg in places where it has no business being.
- morelisp 3y ago
  Besides the actual tools mentioned, TOFU works basically as well as signatures. Just that already generates a noisy-enough false positive rate.