3 ms·

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

> 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
  - bombolo 3y ago
    It seems pypi should launch their own new keyserver, rather than removing PGP. In any event, they will ask for a photo of the ID in the future. Google has already written on their security blog that this is where they're going, and from the whole google titan keys event, we know who decides on behalf of pypi.
    - masklinn 3y ago
      Pypi doesn’t have the resources it needs to do its own job, they’re not going to waste more resources they don’t have on a dead-end technology they don’t have a use for.
slaymaker1907 3y ago
There is some security even if they provide the public key. Bootstrapping is a problem, but clients can keep track of a mapping from package names to public key and issue a warning if that ever changes. That’s how SSH and RDP works and while I’ve never had an actual security hole plugged with this, I’ve had cases where my remote machine went down so the DNS didn’t update yet the IP was reassigned so the warning about mismatching keys was actually helpful.
- woodruffw 3y ago
  > There is some security even if they provide the public key. That security is integrity, which PyPI already provides through strong cryptographic digests of each package distribution. Codesigning schemes need to provide authenticity, not just integrity; a codesigning scheme that's downgradeable to arbitrary key trust is a more complicated than necessary hashing scheme.
- donaldstufft 3y ago
  The problem with TOFU is that it assumes long lived keys (itself a bad practice) OR it assumes that the end user will be fine with regular notices that the keys that have signed their packages have changed, and will be able to correctly differentiate false positives from real positives.
zimmerfrei 3y ago
>> 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. Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the *authors* remained the same, whoever they are. >> 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 Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. People *really* want to mitigate the risk of pypi infrastructure getting fully compromised, which is very likely, given how many eggs you keep in the same basket there. PGP signatures were the last ditch, not very convenient but also not as bad as they are painted. But from now on there will be not even that very little.
- Beldin 3y ago
  > that's what's your HTTPS certificate is for. Not really... That certificate doesn't go back in time. If a domain expires, an attacker could reregister it under their name and get a valid certificate. You'd be downloading from the right domain name with a valid HTTPS certificate, but you're not downloading from the same place as before.
  - recursive 3y ago
    > That certificate doesn't go back in time. It does, kind of, if it's pinned.
    - dgrove 3y ago
      HKPK doesn't have a ton of adoption and only works in browsers. So this does nothing for curl, wget, pip
- woodruffw 3y ago
  > Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are. The point is that they don't remain the same. Assuming that they do is an operational error. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. HTTPS provides transport security, i.e. an authenticity relationship between you and GitHub's servers. It doesn't provide artifact authenticity for the source on that server, and cannot. That's what the comment above is referring to.
alerighi 3y ago
> 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). Depends. If the distributor maintains a repository of trusted public keys (for example as repositories of Linux distributions do) it gives you a guarantee. As it's said, most of the time you just want to know that the key used to sign a package is not changed. That is the same level of security that SSH offers (first time you connect to a server saves the public key, then give an error if that public key is changed). That is really enough for a package in PyPy, or sign git commits and similar. We should ask ourself if the complexity of PGP is needed. Probably not, as it's not needed the complexity of x509 certificates, since a simple RSA signature of the package with a public key hosted on a server would be sufficient. But PGP is practical, you have a good tooling built around it, is pretty universal, so why not?
still_grokking 3y ago
[flagged]
- deleted 3y ago
  [deleted]

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
- bombolo 3y ago
  It seems pypi should launch their own new keyserver, rather than removing PGP. In any event, they will ask for a photo of the ID in the future. Google has already written on their security blog that this is where they're going, and from the whole google titan keys event, we know who decides on behalf of pypi.
  - masklinn 3y ago
    Pypi doesn’t have the resources it needs to do its own job, they’re not going to waste more resources they don’t have on a dead-end technology they don’t have a use for.

slaymaker1907 3y ago

There is some security even if they provide the public key. Bootstrapping is a problem, but clients can keep track of a mapping from package names to public key and issue a warning if that ever changes. That’s how SSH and RDP works and while I’ve never had an actual security hole plugged with this, I’ve had cases where my remote machine went down so the DNS didn’t update yet the IP was reassigned so the warning about mismatching keys was actually helpful.

woodruffw 3y ago
> There is some security even if they provide the public key. That security is integrity, which PyPI already provides through strong cryptographic digests of each package distribution. Codesigning schemes need to provide authenticity, not just integrity; a codesigning scheme that's downgradeable to arbitrary key trust is a more complicated than necessary hashing scheme.
donaldstufft 3y ago
The problem with TOFU is that it assumes long lived keys (itself a bad practice) OR it assumes that the end user will be fine with regular notices that the keys that have signed their packages have changed, and will be able to correctly differentiate false positives from real positives.

zimmerfrei 3y ago

>> 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. Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the *authors* remained the same, whoever they are. >> 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 Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. People *really* want to mitigate the risk of pypi infrastructure getting fully compromised, which is very likely, given how many eggs you keep in the same basket there. PGP signatures were the last ditch, not very convenient but also not as bad as they are painted. But from now on there will be not even that very little.

Beldin 3y ago
> that's what's your HTTPS certificate is for. Not really... That certificate doesn't go back in time. If a domain expires, an attacker could reregister it under their name and get a valid certificate. You'd be downloading from the right domain name with a valid HTTPS certificate, but you're not downloading from the same place as before.
- recursive 3y ago
  > That certificate doesn't go back in time. It does, kind of, if it's pinned.
  - dgrove 3y ago
    HKPK doesn't have a ton of adoption and only works in browsers. So this does nothing for curl, wget, pip
woodruffw 3y ago
> Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are. The point is that they don't remain the same. Assuming that they do is an operational error. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. HTTPS provides transport security, i.e. an authenticity relationship between you and GitHub's servers. It doesn't provide artifact authenticity for the source on that server, and cannot. That's what the comment above is referring to.

alerighi 3y ago

> 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). Depends. If the distributor maintains a repository of trusted public keys (for example as repositories of Linux distributions do) it gives you a guarantee. As it's said, most of the time you just want to know that the key used to sign a package is not changed. That is the same level of security that SSH offers (first time you connect to a server saves the public key, then give an error if that public key is changed). That is really enough for a package in PyPy, or sign git commits and similar. We should ask ourself if the complexity of PGP is needed. Probably not, as it's not needed the complexity of x509 certificates, since a simple RSA signature of the package with a public key hosted on a server would be sufficient. But PGP is practical, you have a good tooling built around it, is pretty universal, so why not?

still_grokking 3y ago

[flagged]

deleted 3y ago
[deleted]