4 ms·

> In the last 3 years, about 50k signatures had been uploaded to PyPI by 1069 unique keys. Of those 1069 unique keys, about 30% of them were not discoverable on

by tzs 3y ago

> In the last 3 years, about 50k signatures had been uploaded to PyPI by 1069 unique keys. Of those 1069 unique keys, about 30% of them were not discoverable on major public keyservers, making it difficult or impossible to meaningfully verify those signatures. Of the remaining 71%, nearly half of them were unable to be meaningfully verified at the time of the audit (2023-05-19) Why not include the public key in the package? 99% of the time what I want out of package signing is to know that the new version of the package I'm downloading is from the same people as the old version. I don't actually need to know who those people are...just that they are the same people as before.

hannob 3y ago
What happens if the developer looses his key? Or if it expires? pypi could show a warning that the key has changed. Which is not an actionable or helpful warning. And then everyone gets used to seeing these warnings every now and then. And you won nothing. Getting signatures to do something useful is hard.
- bombolo 3y ago
  > What happens if the developer looses his key? Or if it expires? What happens if a developer loses their google titan key that is required to login into pypi?
  - hannob 3y ago
    They either have their backup codes or there's probably a manual process the pypi team can get them their account back if they can sufficiently show they are the real developers. If you have any form of automated signature verification you basically need a concept how to handle recovery. But if this concept comes down to "trust pypi", then you really can just skip the whole thing and rely on pypi giving you the right packages and https to secure the connection).
woodruffw 3y ago
> Why not include the public key in the package? Because PyPI (or an attacker) could always substitute a new key. There's very little value in the signature and key coming from the same source: the key (and its justified identity) always need to come from a source of trust, not the source that's being verified. > 99% of the time what I want out of package signing is to know that the new version of the package I'm downloading is from the same people as the old version. I don't actually need to know who those people are...just that they are the same people as before. This might be a misunderstanding, but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manually resolve each new human identity that appears for a package distribution. What most people actually want is a strong cryptographic attestation that the package distribution came from the same source as the thing hosting the source code, since both that service and the owner of the repository are presumed trusted. Notably, PGP is incapable of providing either of these: you only get key IDs, which are neither strong human identities nor a strong binding to a service. Key IDs might correspond to keys with email (or other identities) in them, but that's (1) not guaranteed, and (2) not a strong proof of identity (since anybody can claim any identity in a PGP key).
- specialist 3y ago
  > Because PyPI ... could always substitute a new key. Isn't that what public key servers are for? For publishing my FOSS to sonatype, I had to first publish my public key, eg keyserver.ubuntu.com. I don't know PyPI, but from this OC, it sounds like PyPI does not have the same prerequisite.
  - woodruffw 3y ago
    Yep. Unfortunately, PGP's keyserver network has been dead for years[1]. There are two big (non-synchronizing) ones left, and they're the two I used to do the analysis that's linked in this announcement (meaning they're the ones that are largely missing well-formed keys for the signatures on PyPI). This was discussed a bit on Sunday's thread[2], and my understanding is that Maven's ability to use PGP in this way is effectively due to Sonatype assuming a large amount of operational and maintenance burden. PyPI doesn't have those kind of resources available to it. Even assuming that the service was gifted that kind of support, it would still cause a lot of heartburn with existing signatures and carry forwards all of the legacy baggage of PGP that we're trying to eliminate entirely. [1]: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695... [2]: https://news.ycombinator.com/item?id=36021172 https://news.ycombinator.com/item?id=36021172
still_grokking 3y ago
Did I just witness the invention of a kind of "software package blockchain"? If would be btw. a proper but sustainable prove of work blockchain. As you would need in most cases to pay developers to "mint new blocks". OK, maybe let's forget about the blockchain. It's a loaded term. But the idea of software signature TOFU sounds indeed good!
- chaxor 3y ago
  Anyone that combats something based on the name alone isn't really worth listening to. There can be great use cases for Blockchain just like this, wherein the proof of work is less taxing, or optional. Of course, HN has a rabid response towards the term alone, but these technologies actually can provide some great solutions to a more robust form of git lfs, dockerhub, or huggingface model centralization that will inevitably fail at some point.
  - still_grokking 3y ago
    > There can be great use cases for Blockchain just like this, wherein the proof of work is less taxing, or optional. The prove of work part was more of a joke, I admit. Developers "mining" "software package blocks" is not really "prove of work" (even it is in some sense of course). :-) > but these technologies actually can provide some great solutions to a more robust form of git lfs, dockerhub, or huggingface model centralization Well, that's the Merkle trees part of the tech. You don't need any "blockchain" for that. Something like IPFS ( https://ipfs.tech/ https://ipfs.tech/ ) is for example a nice demonstration of that. But yes, there are useful applications of blockchains. Like https://www.namecoin.org/ https://www.namecoin.org/ But those are really rare.
    - chaxor 3y ago
      You're right that Merkle trees are useful here, but adding proof of work to, e.g. run the code to produce some lfs data (database, NN weights, physical parameters, etc), which is checked by a checksum, could be a fantastic addition for ensuring reproducibility in science. IPFS could be great for reproducibility if the commit hash was linked directly to the data checksum. Blockchain may not be necessary, but it could be an easier implementation of this feature.

by tzs 3y ago

hannob 3y ago

What happens if the developer looses his key? Or if it expires? pypi could show a warning that the key has changed. Which is not an actionable or helpful warning. And then everyone gets used to seeing these warnings every now and then. And you won nothing. Getting signatures to do something useful is hard.

bombolo 3y ago
> What happens if the developer looses his key? Or if it expires? What happens if a developer loses their google titan key that is required to login into pypi?
- hannob 3y ago
  They either have their backup codes or there's probably a manual process the pypi team can get them their account back if they can sufficiently show they are the real developers. If you have any form of automated signature verification you basically need a concept how to handle recovery. But if this concept comes down to "trust pypi", then you really can just skip the whole thing and rely on pypi giving you the right packages and https to secure the connection).

woodruffw 3y ago

> Why not include the public key in the package? Because PyPI (or an attacker) could always substitute a new key. There's very little value in the signature and key coming from the same source: the key (and its justified identity) always need to come from a source of trust, not the source that's being verified. > 99% of the time what I want out of package signing is to know that the new version of the package I'm downloading is from the same people as the old version. I don't actually need to know who those people are...just that they are the same people as before. This might be a misunderstanding, but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manually resolve each new human identity that appears for a package distribution. What most people actually want is a strong cryptographic attestation that the package distribution came from the same source as the thing hosting the source code, since both that service and the owner of the repository are presumed trusted. Notably, PGP is incapable of providing either of these: you only get key IDs, which are neither strong human identities nor a strong binding to a service. Key IDs might correspond to keys with email (or other identities) in them, but that's (1) not guaranteed, and (2) not a strong proof of identity (since anybody can claim any identity in a PGP key).

specialist 3y ago
> Because PyPI ... could always substitute a new key. Isn't that what public key servers are for? For publishing my FOSS to sonatype, I had to first publish my public key, eg keyserver.ubuntu.com. I don't know PyPI, but from this OC, it sounds like PyPI does not have the same prerequisite.
- woodruffw 3y ago
  Yep. Unfortunately, PGP's keyserver network has been dead for years[1]. There are two big (non-synchronizing) ones left, and they're the two I used to do the analysis that's linked in this announcement (meaning they're the ones that are largely missing well-formed keys for the signatures on PyPI). This was discussed a bit on Sunday's thread[2], and my understanding is that Maven's ability to use PGP in this way is effectively due to Sonatype assuming a large amount of operational and maintenance burden. PyPI doesn't have those kind of resources available to it. Even assuming that the service was gifted that kind of support, it would still cause a lot of heartburn with existing signatures and carry forwards all of the legacy baggage of PGP that we're trying to eliminate entirely. [1]: https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d695... [2]: https://news.ycombinator.com/item?id=36021172 https://news.ycombinator.com/item?id=36021172

still_grokking 3y ago

Did I just witness the invention of a kind of "software package blockchain"? If would be btw. a proper but sustainable prove of work blockchain. As you would need in most cases to pay developers to "mint new blocks". OK, maybe let's forget about the blockchain. It's a loaded term. But the idea of software signature TOFU sounds indeed good!

chaxor 3y ago
Anyone that combats something based on the name alone isn't really worth listening to. There can be great use cases for Blockchain just like this, wherein the proof of work is less taxing, or optional. Of course, HN has a rabid response towards the term alone, but these technologies actually can provide some great solutions to a more robust form of git lfs, dockerhub, or huggingface model centralization that will inevitably fail at some point.
- still_grokking 3y ago
  > There can be great use cases for Blockchain just like this, wherein the proof of work is less taxing, or optional. The prove of work part was more of a joke, I admit. Developers "mining" "software package blocks" is not really "prove of work" (even it is in some sense of course). :-) > but these technologies actually can provide some great solutions to a more robust form of git lfs, dockerhub, or huggingface model centralization Well, that's the Merkle trees part of the tech. You don't need any "blockchain" for that. Something like IPFS ( https://ipfs.tech/ https://ipfs.tech/ ) is for example a nice demonstration of that. But yes, there are useful applications of blockchains. Like https://www.namecoin.org/ https://www.namecoin.org/ But those are really rare.
  - chaxor 3y ago
    You're right that Merkle trees are useful here, but adding proof of work to, e.g. run the code to produce some lfs data (database, NN weights, physical parameters, etc), which is checked by a checksum, could be a fantastic addition for ensuring reproducibility in science. IPFS could be great for reproducibility if the commit hash was linked directly to the data checksum. Blockchain may not be necessary, but it could be an easier implementation of this feature.