3 ms·

So PyPI acts as keyserver, and basically a CSR signer for sub-CA wildcard package signing certs, and the package+key mapping trusted authority; and Sigstore act

So PyPI acts as keyserver, and basically a CSR signer for sub-CA wildcard package signing certs, and the package+key mapping trusted authority; and Sigstore acts as signature server; and both are centralized? And something has to call cosign (?) to determine what value to pass to `twine --attestations`? Blockcerts with DID identities is the W3C way to do Software Supply Chain Security like what SLSA.dev describes FWIU. And then now it's possible to upload packages and native containers to OCI container repositories, which support artifact signatures with TUF since docker notary; but also not yet JSON-LD/YAML-LD that simply joins with OSV OpenSSF and SBOM Linked Data on registered (GitHub, PyPI, conda-forge, deb-src,) namespace URIs. GitHub supports requiring GPG signatures on commits. Git commits are precedent to what gets merged and later released. A rough chronology of specs around these problems: {SSH, GPG, TLS w/ CA cert bundles, WebID, OpenID, HOTP/TOTP, Bitcoin, WebID-TLS, TOTP, OIDC OpenID Connect (TLS, HTTP, JSON, OAuth2.0, JWT), TUF, Uptane, CT Logs, WebAuthn, W3C DID, Blockcerts, SOLID-OIDC, Shamir Backup, transferable passkeys, } For PyPI: PyPI.org, TLS, OIDC OpenID Connect, twine, pip, cosign, and Sigstore.dev. Sigstore Rekor has centralized Merkle hashes like google/trillian which centralizedly hosts Certificate Transparency logs of x509 certs grants and revocations by Certificate Authorities. W3C DID Decentralized Identifiers [did-core] > 9.8 Verification Method Revocation : https://www.w3.org/TR/did-core/#verification-method-revocation https://www.w3.org/TR/did-core/#verification-method-revocati... : > If a verification method is no longer exclusively accessible to the controller or parties trusted to act on behalf of the controller, it is expected to be revoked immediately to reduce the risk of compromises such as masquerading, theft, and fraud

woodruffw 2y ago
> So PyPI acts as keyserver, and basically a CSR signer for sub-CA wildcard package signing certs, and the package+key mapping trusted authority; and Sigstore acts as signature server; and both are centralized? No -- there is no keyserver per se in PEP 740's design, because PEP 740 is built around identity binding instead of long-lived signing keys. PyPI does no signing at all and has no CA or CSR components; it acts only as an attestation store for attestations, which it verifies on upload.
- westurner 2y ago
  PyPI signs uploaded packages with its signing key per PEP 458: https://peps.python.org/pep-0458/ https://peps.python.org/pep-0458/ : > This [PEP 458 security] model supports verification of PyPI distributions that are signed with keys stored on PyPI So that's deprecated by PEP 740 now? PEP 740: https://peps.python.org/pep-0740/ https://peps.python.org/pep-0740/ : > In addition to the current top-level `content` and `gpg_signature` fields, the index SHALL accept `attestations` as an additional multipart form field. > The new `attestations` field SHALL be a JSON array. > The `attestations` array SHALL have one or more items, each a JSON object representing an individual attestation. > Each attestation object MUST be verifiable by the index. If the index fails to verify any attestation in attestations, it MUST reject the upload. The format of attestation objects is defined under Attestation objects and the process for verifying attestations is defined under Attestation verification. What is the worst case resource cost of an attestation validation required of PyPI? blockchain-certificates/cert-verifier-js; https://westurner.github.io/hnlog/ https://westurner.github.io/hnlog/ Ctrl-F verifier-js `attestations` and/or `gpg_signature`; From https://news.ycombinator.com/item?id=39204722 https://news.ycombinator.com/item?id=39204722 : > An example of GPG signatures on linked data documents: https://gpg.jsld.org/contexts/#GpgSignature2020 https://gpg.jsld.org/contexts/#GpgSignature2020 W3C DID self-generated keys also work with VC linked data; could a new field like the `attestations` field solve for DID signatures on the JSON metadata; or is that still centralized and not zero trust?
  - westurner 2y ago
    (My mistake: PyPI is not a keyserver, and Sigstore is not a keyserver)

woodruffw 2y ago

> So PyPI acts as keyserver, and basically a CSR signer for sub-CA wildcard package signing certs, and the package+key mapping trusted authority; and Sigstore acts as signature server; and both are centralized? No -- there is no keyserver per se in PEP 740's design, because PEP 740 is built around identity binding instead of long-lived signing keys. PyPI does no signing at all and has no CA or CSR components; it acts only as an attestation store for attestations, which it verifies on upload.

westurner 2y ago
PyPI signs uploaded packages with its signing key per PEP 458: https://peps.python.org/pep-0458/ https://peps.python.org/pep-0458/ : > This [PEP 458 security] model supports verification of PyPI distributions that are signed with keys stored on PyPI So that's deprecated by PEP 740 now? PEP 740: https://peps.python.org/pep-0740/ https://peps.python.org/pep-0740/ : > In addition to the current top-level `content` and `gpg_signature` fields, the index SHALL accept `attestations` as an additional multipart form field. > The new `attestations` field SHALL be a JSON array. > The `attestations` array SHALL have one or more items, each a JSON object representing an individual attestation. > Each attestation object MUST be verifiable by the index. If the index fails to verify any attestation in attestations, it MUST reject the upload. The format of attestation objects is defined under Attestation objects and the process for verifying attestations is defined under Attestation verification. What is the worst case resource cost of an attestation validation required of PyPI? blockchain-certificates/cert-verifier-js; https://westurner.github.io/hnlog/ https://westurner.github.io/hnlog/ Ctrl-F verifier-js `attestations` and/or `gpg_signature`; From https://news.ycombinator.com/item?id=39204722 https://news.ycombinator.com/item?id=39204722 : > An example of GPG signatures on linked data documents: https://gpg.jsld.org/contexts/#GpgSignature2020 https://gpg.jsld.org/contexts/#GpgSignature2020 W3C DID self-generated keys also work with VC linked data; could a new field like the `attestations` field solve for DID signatures on the JSON metadata; or is that still centralized and not zero trust?
- westurner 2y ago
  (My mistake: PyPI is not a keyserver, and Sigstore is not a keyserver)