5 ms·

Why is OpenID used instead of, for example, the already git-integrated gpg signed commits? Wouldn't a list of gpg keys be more decentralized from third party a

Why is OpenID used instead of, for example, the already git-integrated gpg signed commits? Wouldn't a list of gpg keys be more decentralized from third party auth providers?

woodruffw 4y ago
On a general level: PGP is a very difficult ecosystem to integrate correctly and safely[1]. It's also only one of several signing schemes supported by `git`, and arguably the worst of them (in terms of excessive complexity, poor defaults, and format/cipher agility). More specifically to trusted publishing: the idea is to bind a PyPI project to its source repository (or repositories) for CI-based releases. PGP signatures wouldn't really accomplish this; it'd be closer to using PGP as an authentication system. And at that point you're just doing API tokens but with more steps and a shakier foundation (per above), which PyPI already supports. An identity provider is a fundamental assumption in trusted publishing; API tokens will continue to work as a "decentralized" alternative if using an IdP is unacceptable for your particular use case. [1]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html
- benatkin 4y ago
  When you sign commits, the signature includes the parent commit. So it includes the version, and you can use it to verify something before publishing. This way the API keys could be included in CI much more safely. You would need to make it so that there's a setting in an account so an API key is useless to publish without a signed commit. It's simple, open, and works well. Edit: if you can't publish the same version twice it enables someone with a stolen API key to publish something after it's bumped but before the CI runs. That's a far fetched scenario.
  - woodruffw 4y ago
    > You would need to make it so that there's a setting in an account so an API key is useless to publish without a signed commit. That’s the “easy” part. The hard part is determining what constitutes a valid PGP identity, as well as inheriting all of the baggage that comes with PGP (including things that nobody wants to deal with, like revocation). And again: this would be explicitly forcing users into a known bad signing mechanism, one that only applies to git. Trusted publishing as-implemented does not have these problems.
    - benatkin 4y ago
      It's not bad. Just because you reference some post doesn't make it a fact and not an opinion: "The answer is that they shouldn’t be telling you that, because PGP is bad and needs to go away." - says some micro.blog GPG is very much current technology. The code forges provide APIs for public keys, so some of the difficulties are handled already. https://docs.gitlab.com/ee/api/users.html#list-all-gpg-keys-for-given-user https://docs.gitlab.com/ee/api/users.html#list-all-gpg-keys-...
      - woodruffw 4y ago
        It’s a pretty well known blog, from a pretty well known security company. I would also go as far as to say that “PGP is bad and should not be used for greenfield projects” is not a remotely controversial opinion in applied cryptography circles. Likewise, it is not controversial in those circles to assert that PGP is more or less the opposite of current technology for digital signatures. Some more helpful links by generally recognized authorities[1][2]. You’ll note that each of these is more than a few years old at this point; PGP’s deficiencies are very well trodden. [1]: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2]: https://words.filippo.io/giving-up-on-long-term-pgp/ https://words.filippo.io/giving-up-on-long-term-pgp/
        benatkin 4y ago
        Well I don't buy into this cancelling of open tech.
        woodruffw 4y ago
        There is no meaningful sense in which PGP is “canceled”, except in the kind of shitpost sense I would use in a talk slide. Open alternatives exist, are better, and have been better for well over a decade at this point. No significant risk is posed to “open tech” by doing things better than PGP can possibly offer us.
0xbadcafebee 4y ago
Decentralization always makes things more complicated, but not always better.

Why is OpenID used instead of, for example, the already git-integrated gpg signed commits? Wouldn't a list of gpg keys be more decentralized from third party auth providers?

woodruffw 4y ago

On a general level: PGP is a very difficult ecosystem to integrate correctly and safely[1]. It's also only one of several signing schemes supported by `git`, and arguably the worst of them (in terms of excessive complexity, poor defaults, and format/cipher agility). More specifically to trusted publishing: the idea is to bind a PyPI project to its source repository (or repositories) for CI-based releases. PGP signatures wouldn't really accomplish this; it'd be closer to using PGP as an authentication system. And at that point you're just doing API tokens but with more steps and a shakier foundation (per above), which PyPI already supports. An identity provider is a fundamental assumption in trusted publishing; API tokens will continue to work as a "decentralized" alternative if using an IdP is unacceptable for your particular use case. [1]: https://latacora.micro.blog/2019/07/16/the-pgp-problem.html https://latacora.micro.blog/2019/07/16/the-pgp-problem.html

benatkin 4y ago
When you sign commits, the signature includes the parent commit. So it includes the version, and you can use it to verify something before publishing. This way the API keys could be included in CI much more safely. You would need to make it so that there's a setting in an account so an API key is useless to publish without a signed commit. It's simple, open, and works well. Edit: if you can't publish the same version twice it enables someone with a stolen API key to publish something after it's bumped but before the CI runs. That's a far fetched scenario.
- woodruffw 4y ago
  > You would need to make it so that there's a setting in an account so an API key is useless to publish without a signed commit. That’s the “easy” part. The hard part is determining what constitutes a valid PGP identity, as well as inheriting all of the baggage that comes with PGP (including things that nobody wants to deal with, like revocation). And again: this would be explicitly forcing users into a known bad signing mechanism, one that only applies to git. Trusted publishing as-implemented does not have these problems.
  - benatkin 4y ago
    It's not bad. Just because you reference some post doesn't make it a fact and not an opinion: "The answer is that they shouldn’t be telling you that, because PGP is bad and needs to go away." - says some micro.blog GPG is very much current technology. The code forges provide APIs for public keys, so some of the difficulties are handled already. https://docs.gitlab.com/ee/api/users.html#list-all-gpg-keys-for-given-user https://docs.gitlab.com/ee/api/users.html#list-all-gpg-keys-...
    - woodruffw 4y ago
      It’s a pretty well known blog, from a pretty well known security company. I would also go as far as to say that “PGP is bad and should not be used for greenfield projects” is not a remotely controversial opinion in applied cryptography circles. Likewise, it is not controversial in those circles to assert that PGP is more or less the opposite of current technology for digital signatures. Some more helpful links by generally recognized authorities[1][2]. You’ll note that each of these is more than a few years old at this point; PGP’s deficiencies are very well trodden. [1]: https://blog.cryptographyengineering.com/2014/08/13/whats-matter-with-pgp/ https://blog.cryptographyengineering.com/2014/08/13/whats-ma... [2]: https://words.filippo.io/giving-up-on-long-term-pgp/ https://words.filippo.io/giving-up-on-long-term-pgp/
      - benatkin 4y ago
        Well I don't buy into this cancelling of open tech.
        woodruffw 4y ago
        There is no meaningful sense in which PGP is “canceled”, except in the kind of shitpost sense I would use in a talk slide. Open alternatives exist, are better, and have been better for well over a decade at this point. No significant risk is posed to “open tech” by doing things better than PGP can possibly offer us.

0xbadcafebee 4y ago

Decentralization always makes things more complicated, but not always better.