3 ms·

(2) is addressed by Sigstore having its own infrastructure and a full-time rotation staff. PyPI doesn't need to run or operationalize anything, which is a signi

(2) is addressed by Sigstore having its own infrastructure and a full-time rotation staff. PyPI doesn't need to run or operationalize anything, which is a significant relief compared to the prospect of having to operationalize a PGP keyserver with volunteer staffing. (I'm intentionally glossing over details here, like the fact that PyPI doesn't need to perform any online operations to validate Sigstore's signatures. The bottom line is that everything about it is operationally simpler and more modern than could be shaped out of the primitives PGP offers.) (4) could be done with PGP, but would go against the long-standing pattern of "sign the file" that most PGP tooling is ossified around. It also doesn't change the fact that PGP's signing defaults aren't great, that there's a huge tail of junk signing keys out there, and that to address those problems PyPI would need to be in the business of parsing PGP packets during package upload. That's just not a good use of anybody's time.

opello 2y ago
> having its own infrastructure This seems like a different brand of the keyserver network? > PyPI doesn't need to run or operationalize anything So it's not a new operational dependency because it's index metadata? That seems more like an implementation detail (aside from the imagined PGP keyserver dependency) that seems accommodatable given either system. > like the fact that PyPI doesn't need to perform any online operations to validate Sigstore's signatures I may be missing something subtle (or glaring) but "online operations" would be interactions with some other service or a non-PSF service? Or simply a service not-wholly-pypi? Regardless, the index seems like it must be a "verifier" for design consideration (2) from PEP 740 to hold, which would mean that the index must perform the verification step on the uploaded data--which seems inconsequentially different between an imagined PGP system (other than it would have to access the imagined PyPI keyserver) and sigstore/in-toto. > ... PyPI would need to be in the business of parsing PGP packets during package upload. But the sigstore analog is the JSON array of in-toto attestation statement objects.
- woodruffw 2y ago
  > This seems like a different brand of the keyserver network? It serves a vaguely similar purpose, if that's what you mean. That shouldn't be surprising, since this is all PKI-shaped problems under the hood. To reiterate: the operational constraints here are (1) simplicity and reliability for PyPI, plus secure defaults for the signing scheme itself. Running a PGP keyserver would not offer (1), and PGP as an ecosystem does not offer (2). This is even before desired properties, like strong identity binding, which PGP cannot offer in its current form. > "online operations" would be interactions with some other service or a non-PSF service? Or simply a service not-wholly-pypi? In the PGP setting, that means PyPI would need to pull from a keyserver. That keyserver would need to be one that PyPI doesn't control in order for the threat model to be coherent. In the PEP 740 setting, PyPI does not need to pull any material from anywhere besides what the uploader is providing: the signatures in the attestations uploaded are signed with an attacked ephemeral signing certificate, which has a trusted publisher as its identity. That signing certificate can then be chained to an already established root of trust, in "normal" X.509 PKI fashion. You could approximate this design with PGP, but none of the primitives currently exist (or if they exist, are inoperational). > But the sigstore analog is the JSON array of in-toto attestation statement objects. Yes. Believe it or not, a big ugly JSON blob is simpler than dealing with PGP's mess of packet versions and formats.
  - opello 2y ago
    > This is even before desired properties, like strong identity binding, which PGP cannot offer in its current form. If the strong identity binding is OIDC then I disagree. It's convenient but no more evidence of identity than being able to unlock a private key. > ... one that PyPI doesn't control in order for the threat model to be coherent. This doesn't make sense unless the author key material was only ever published on the PyPI keyserver. > PyPI does not need to pull any material from anywhere besides what the uploader is providing > in "normal" X.509 PKI fashion. What about checking for revocation?
    - woodruffw 2y ago
      > If the strong identity binding is OIDC then I disagree. It's convenient but no more evidence of identity than being able to unlock a private key. Modulo the security of the OIDC provider, it's a very strong proof of identity. The world already assumes this in practice (via pervasive OAuth and OIDC in other contexts); all PEP 740 does is make the same assumption rather than trying to bolt strong identity onto PGP. (I think there are good objections to OIDC, including the risk of centralization. But I've yet to see a better widely adopted system for publicly verifying identity claims.) > This doesn't make sense unless the author key material was only ever published on the PyPI keyserver. Is there any evidence that anybody is reconciling results from different PGP keyservers? I don't think anybody was doing this even at the peak of the SKS network. (But even this assumes more sophistication than the average user is putting into verification: 99% of Python distribution installations aren't doing even hash-checking. Expecting that users will begin to do keyring curation isn't reasonable, and - critically - is not empirically supported by the last 2 decades of PGP support on PyPI.) > What about checking for revocation? PEP 740 assumes short-lived (~10 minute) signing certificates with ephemeral signing keys. Subscriber-level revocation hasn't scaled well for the Web PKI, so the underlying stack here (Sigstore) prefers limiting the scope of signing materials and enforcing transparency instead.

opello 2y ago

> having its own infrastructure This seems like a different brand of the keyserver network? > PyPI doesn't need to run or operationalize anything So it's not a new operational dependency because it's index metadata? That seems more like an implementation detail (aside from the imagined PGP keyserver dependency) that seems accommodatable given either system. > like the fact that PyPI doesn't need to perform any online operations to validate Sigstore's signatures I may be missing something subtle (or glaring) but "online operations" would be interactions with some other service or a non-PSF service? Or simply a service not-wholly-pypi? Regardless, the index seems like it must be a "verifier" for design consideration (2) from PEP 740 to hold, which would mean that the index must perform the verification step on the uploaded data--which seems inconsequentially different between an imagined PGP system (other than it would have to access the imagined PyPI keyserver) and sigstore/in-toto. > ... PyPI would need to be in the business of parsing PGP packets during package upload. But the sigstore analog is the JSON array of in-toto attestation statement objects.

woodruffw 2y ago
> This seems like a different brand of the keyserver network? It serves a vaguely similar purpose, if that's what you mean. That shouldn't be surprising, since this is all PKI-shaped problems under the hood. To reiterate: the operational constraints here are (1) simplicity and reliability for PyPI, plus secure defaults for the signing scheme itself. Running a PGP keyserver would not offer (1), and PGP as an ecosystem does not offer (2). This is even before desired properties, like strong identity binding, which PGP cannot offer in its current form. > "online operations" would be interactions with some other service or a non-PSF service? Or simply a service not-wholly-pypi? In the PGP setting, that means PyPI would need to pull from a keyserver. That keyserver would need to be one that PyPI doesn't control in order for the threat model to be coherent. In the PEP 740 setting, PyPI does not need to pull any material from anywhere besides what the uploader is providing: the signatures in the attestations uploaded are signed with an attacked ephemeral signing certificate, which has a trusted publisher as its identity. That signing certificate can then be chained to an already established root of trust, in "normal" X.509 PKI fashion. You could approximate this design with PGP, but none of the primitives currently exist (or if they exist, are inoperational). > But the sigstore analog is the JSON array of in-toto attestation statement objects. Yes. Believe it or not, a big ugly JSON blob is simpler than dealing with PGP's mess of packet versions and formats.
- opello 2y ago
  > This is even before desired properties, like strong identity binding, which PGP cannot offer in its current form. If the strong identity binding is OIDC then I disagree. It's convenient but no more evidence of identity than being able to unlock a private key. > ... one that PyPI doesn't control in order for the threat model to be coherent. This doesn't make sense unless the author key material was only ever published on the PyPI keyserver. > PyPI does not need to pull any material from anywhere besides what the uploader is providing > in "normal" X.509 PKI fashion. What about checking for revocation?
  - woodruffw 2y ago
    > If the strong identity binding is OIDC then I disagree. It's convenient but no more evidence of identity than being able to unlock a private key. Modulo the security of the OIDC provider, it's a very strong proof of identity. The world already assumes this in practice (via pervasive OAuth and OIDC in other contexts); all PEP 740 does is make the same assumption rather than trying to bolt strong identity onto PGP. (I think there are good objections to OIDC, including the risk of centralization. But I've yet to see a better widely adopted system for publicly verifying identity claims.) > This doesn't make sense unless the author key material was only ever published on the PyPI keyserver. Is there any evidence that anybody is reconciling results from different PGP keyservers? I don't think anybody was doing this even at the peak of the SKS network. (But even this assumes more sophistication than the average user is putting into verification: 99% of Python distribution installations aren't doing even hash-checking. Expecting that users will begin to do keyring curation isn't reasonable, and - critically - is not empirically supported by the last 2 decades of PGP support on PyPI.) > What about checking for revocation? PEP 740 assumes short-lived (~10 minute) signing certificates with ephemeral signing keys. Subscriber-level revocation hasn't scaled well for the Web PKI, so the underlying stack here (Sigstore) prefers limiting the scope of signing materials and enforcing transparency instead.