4 ms·

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

>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. I don't know if it applies to any of those 1069 keys, but note that there is a way of hosting PGP keys that does not depend on key servers: WKD https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/16/ https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-s... . You host the key at a .well-known URI under the domain of the email address. It's a draft as you can see, but I've seen a few people using it (including myself), and GnuPG supports it.

woodruffw 3y ago
This is interesting, but it doesn't really solve the key distribution problem: with well-known hosting you now have a (weak) binding to some DNS path, but you're not given any indication of how to discover that path. It's also not clear that a DNS identity is beneficial to PyPI in particular (since PyPI doesn't associate or namespace packages at all w/r/t DNS). More generally, these kinds of improvements are not a sufficient reason to retain PGP: even with a sensible identity binding and key distribution, PGP is still a mess under the hood. The security of a codesigning scheme is always the weakest signature and/or key, and PGP's flexibility more or less ensures that that weakest link will always be extremely weak.
- Arnavion 3y ago
  Right. I've never used PyPI, but TFA makes it sound like the existing support for signing is "We allow the uploader to upload a signature, and the downloader can look up the key indicated in the signature to do the verification." Is that correct? If so, then yes there is a key ID involved but no email address, so a generic downloader would have no choice but to look it up from a key server.
  - woodruffw 3y ago
    That's correct! PyPI's support for PGP is very old -- it's hard to get an exact date, but I think it's been around since the very earliest versions of the index (well before it was a storing index like it is now). If I had to guess (speculate wildly), my guess would be that the original implementation was done with a healthy SKS network and strong set in mind -- without those things, PGP's already weak identity primitives are more or less nonexistent with just signatures.
    - westurner 3y ago
      GPG ASC upload support was quietly added later IIRC. EWDurbin might recall
      - donaldstufft 3y ago
        2005, https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e608608781928b5d5780af77 https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e60860...
        westurner 3y ago
        Well, I think there should be broader discussion of this inadequacy. "Implement "hook" support for package signature verification." (2013) https://github.com/pypi/warehouse/issues/1638#issuecomment-274521719 https://github.com/pypi/warehouse/issues/1638#issuecomment-2... "GPG signing - how does that really work with PyPI?" https://github.com/pypa/twine/issues/157#issuecomment-1014602391 https://github.com/pypa/twine/issues/157#issuecomment-101460... "Better integration with conda/conda-forge for building packages" https://github.com/pyodide/pyodide/issues/795#issuecomment-1250113736 https://github.com/pyodide/pyodide/issues/795#issuecomment-1... Conda now has their own package cryptographic signature software supply chain security control control. Unfortunately, conda's isn't yet W3D DIDs with Verifiable Credentials and sigstore either. Also, [CycloneDX] SBOMs don't have any package archive or package file signatures; so when you try to audit what software you have on all the containers on your infrastructure there's no way to check the cryptographic signatures of the package authors and maintainers against what's installed on disk. docker help sbom # check_signatures python conda zipapps apt/dnf/brew/chocolatey_nuget git /usr/local And without clients signing before uploading, we can only verify Data Integrity (1) at the package archive level; (2) with pypi's package signature key.
Avamander 3y ago
You can't do WKD with just signatures, there are no identities associated with the signature to just look up.

woodruffw 3y ago

This is interesting, but it doesn't really solve the key distribution problem: with well-known hosting you now have a (weak) binding to some DNS path, but you're not given any indication of how to discover that path. It's also not clear that a DNS identity is beneficial to PyPI in particular (since PyPI doesn't associate or namespace packages at all w/r/t DNS). More generally, these kinds of improvements are not a sufficient reason to retain PGP: even with a sensible identity binding and key distribution, PGP is still a mess under the hood. The security of a codesigning scheme is always the weakest signature and/or key, and PGP's flexibility more or less ensures that that weakest link will always be extremely weak.

Arnavion 3y ago
Right. I've never used PyPI, but TFA makes it sound like the existing support for signing is "We allow the uploader to upload a signature, and the downloader can look up the key indicated in the signature to do the verification." Is that correct? If so, then yes there is a key ID involved but no email address, so a generic downloader would have no choice but to look it up from a key server.
- woodruffw 3y ago
  That's correct! PyPI's support for PGP is very old -- it's hard to get an exact date, but I think it's been around since the very earliest versions of the index (well before it was a storing index like it is now). If I had to guess (speculate wildly), my guess would be that the original implementation was done with a healthy SKS network and strong set in mind -- without those things, PGP's already weak identity primitives are more or less nonexistent with just signatures.
  - westurner 3y ago
    GPG ASC upload support was quietly added later IIRC. EWDurbin might recall
    - donaldstufft 3y ago
      2005, https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e608608781928b5d5780af77 https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e60860...
      - westurner 3y ago
        Well, I think there should be broader discussion of this inadequacy. "Implement "hook" support for package signature verification." (2013) https://github.com/pypi/warehouse/issues/1638#issuecomment-274521719 https://github.com/pypi/warehouse/issues/1638#issuecomment-2... "GPG signing - how does that really work with PyPI?" https://github.com/pypa/twine/issues/157#issuecomment-1014602391 https://github.com/pypa/twine/issues/157#issuecomment-101460... "Better integration with conda/conda-forge for building packages" https://github.com/pyodide/pyodide/issues/795#issuecomment-1250113736 https://github.com/pyodide/pyodide/issues/795#issuecomment-1... Conda now has their own package cryptographic signature software supply chain security control control. Unfortunately, conda's isn't yet W3D DIDs with Verifiable Credentials and sigstore either. Also, [CycloneDX] SBOMs don't have any package archive or package file signatures; so when you try to audit what software you have on all the containers on your infrastructure there's no way to check the cryptographic signatures of the package authors and maintainers against what's installed on disk. docker help sbom # check_signatures python conda zipapps apt/dnf/brew/chocolatey_nuget git /usr/local And without clients signing before uploading, we can only verify Data Integrity (1) at the package archive level; (2) with pypi's package signature key.

Avamander 3y ago

You can't do WKD with just signatures, there are no identities associated with the signature to just look up.