4 ms·

PGP didn't make it intractable, the problem is itself intractable... you're referring to the public key infrastructure (PKI)[1] problem, which many have tried t

by brabel 3y ago

PGP didn't make it intractable, the problem is itself intractable... you're referring to the public key infrastructure (PKI)[1] problem, which many have tried to solve and failed. PGP can use the only known solution to the problem, which is letting several key servers be configured by the user to import keys (which can then be verified by checking the key fingerprint on another source which is "trusted", like the publisher's own website). You can still import keys by physically exchanging trusted keys with others (so called Key Signing Party[2]) but that obviously cannot scale... or using any innovative method you come up with, but no one has found a bullet proof way to do this that's usable. But saying PGP only solves half the problem is wrong. It solves one problem: that of how to verify a publisher's artifacts were not modified, which is valuable. The next problem to solve is how to obtain and vet public keys from publishers. The solution could work somewhat like TLS certificates (with certificate authorities playing the role of trusted key servers) or using blockchain (perhaps a rare problem for which blockchain could actually be helpful) but both of these bring their own issues with them. If you know of a better solution, though, do bring it up instead of throwing the bathwater out with the "baby"! [1] https://en.wikipedia.org/wiki/Public_key_infrastructure https://en.wikipedia.org/wiki/Public_key_infrastructure [2] https://en.wikipedia.org/wiki/Key_signing_party https://en.wikipedia.org/wiki/Key_signing_party

lll-o-lll 3y ago
Why sign at all? Isn’t the key requirement that the component was not tampered with after upload? All you need is a hash for that… Tracing back the code to a legal entity seems unnecessary in the majority of cases.
- brabel 3y ago
  Signing is basically hashing + proof of who created the hash. You need either both, or a way to find which hash is correct according to someone, usually the owner of the artifact, and signing gives you just that.
  - lll-o-lll 3y ago
    But a hash provides proof to the actual uploader of subsequent tampering. As you cannot modify the hash without the originator being aware, I think it is enough.
  - woodruffw 3y ago
    Signing is only proof of identity if you (1) know the underlying identity, and (2) actually trust that identity for intelligible reasons (i.e., you can produce a formal description of the trust relationship). Without those two conditions, a signature is a digest produced by an untrusted party. For PyPI, that means that PGP signatures are no better than (and in some senses, worse) than PyPI's own digests, since PyPI at least is a currently trusted party.
    - Groxx 3y ago
      A centralized host can't ever be the only reasonable option for trust. They can be manipulated, technically or socially, and that makes everything vulnerable at once. Both are useful.
      - woodruffw 3y ago
        The Web PKI is built around centralized roots of trust, and survives because of concerted efforts to make those roots resilient, trustworthy (in terms of underlying ownership), and publicly auditable (with mechanisms like CT). To the best of my knowledge, there has never been a successful decentralized PKI. Even the most successful uses of PGP are not decentralized; they're essentially private PKIs maintained by a small set of presumed trustworthy maintainers.
        Groxx 3y ago
        PGP absolutely is decentralized - I can trust or distrust key X without communicating at all with any external PKI. I agree that's not all that useful on a global scale - it essentially degrades to the current PKI setup then, because validating everything is expensive and doesn't need to be done by everyone every time to get nearly all of the benefit. But it is a significant difference for individuals making individual decisions.
woodruffw 3y ago
I think it’d behoove you to read the original thread from yesterday: all, and more, of this was covered! PKI is indeed hard, but it’s not even remotely intractable. The Web PKI is a functioning PKI; yesterday’s thread explains how the codesigning scheme we’re building for PyPI is going to look very similar to the Web PKI. At the ecosystem level, PGP was not providing resource integrity to PyPI: too many of the keys involved were weak, and only a tiny proportion of packages were even signed. Even if that proportion was 100%, PGP would have been the wrong tool for that job: PyPI already has transport and resource integrity via the right tools: TLS and digests. Using an untrusted signature for resource integrity is using the wrong tool for the job. The original thread contains multiple references to Sigstore, which is the scheme we’re planning on building on for PyPI.

by brabel 3y ago

lll-o-lll 3y ago

Why sign at all? Isn’t the key requirement that the component was not tampered with after upload? All you need is a hash for that… Tracing back the code to a legal entity seems unnecessary in the majority of cases.

brabel 3y ago
Signing is basically hashing + proof of who created the hash. You need either both, or a way to find which hash is correct according to someone, usually the owner of the artifact, and signing gives you just that.
- lll-o-lll 3y ago
  But a hash provides proof to the actual uploader of subsequent tampering. As you cannot modify the hash without the originator being aware, I think it is enough.
- woodruffw 3y ago
  Signing is only proof of identity if you (1) know the underlying identity, and (2) actually trust that identity for intelligible reasons (i.e., you can produce a formal description of the trust relationship). Without those two conditions, a signature is a digest produced by an untrusted party. For PyPI, that means that PGP signatures are no better than (and in some senses, worse) than PyPI's own digests, since PyPI at least is a currently trusted party.
  - Groxx 3y ago
    A centralized host can't ever be the only reasonable option for trust. They can be manipulated, technically or socially, and that makes everything vulnerable at once. Both are useful.
    - woodruffw 3y ago
      The Web PKI is built around centralized roots of trust, and survives because of concerted efforts to make those roots resilient, trustworthy (in terms of underlying ownership), and publicly auditable (with mechanisms like CT). To the best of my knowledge, there has never been a successful decentralized PKI. Even the most successful uses of PGP are not decentralized; they're essentially private PKIs maintained by a small set of presumed trustworthy maintainers.
      - Groxx 3y ago
        PGP absolutely is decentralized - I can trust or distrust key X without communicating at all with any external PKI. I agree that's not all that useful on a global scale - it essentially degrades to the current PKI setup then, because validating everything is expensive and doesn't need to be done by everyone every time to get nearly all of the benefit. But it is a significant difference for individuals making individual decisions.

woodruffw 3y ago

I think it’d behoove you to read the original thread from yesterday: all, and more, of this was covered! PKI is indeed hard, but it’s not even remotely intractable. The Web PKI is a functioning PKI; yesterday’s thread explains how the codesigning scheme we’re building for PyPI is going to look very similar to the Web PKI. At the ecosystem level, PGP was not providing resource integrity to PyPI: too many of the keys involved were weak, and only a tiny proportion of packages were even signed. Even if that proportion was 100%, PGP would have been the wrong tool for that job: PyPI already has transport and resource integrity via the right tools: TLS and digests. Using an untrusted signature for resource integrity is using the wrong tool for the job. The original thread contains multiple references to Sigstore, which is the scheme we’re planning on building on for PyPI.