3 ms·

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

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.
        benatkin 4y ago
        If you're bluntly calling it "bad" and I take what you said at face value, that sort of cancels it for me. But yeah, it would continue to exist. I didn't mean to suggest it wouldn't. PGP remains on the table for me. A Microsoft-only launch doesn't.
        woodruffw 4y ago
        There is a strict sense in which PGP does not remain on the table for you, because PyPI does not (and will not, on this developer’s clean conscience) ever support PGP for authentication :-) As said in adjacent threads, PyPI intends to add support for other OIDC providers once they give us the claims we need. Whether or not you choose to use it is ultimately up to you; normal API tokens will continue to work.
        benatkin 4y ago
        It still is, because I can have my CI use it to determine whether to publish a PyPI package. Nice try though. This is definitely a new low for Python. The main issue is just that it was a Microsoft-only launch. All the rest is just window dressing. It's a good reminder about the Pylance situation in Visual Studio Code. Microsoft tricked people into using closed source. https://ghuntley.com/fracture/ https://ghuntley.com/fracture/

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.
      - benatkin 4y ago
        If you're bluntly calling it "bad" and I take what you said at face value, that sort of cancels it for me. But yeah, it would continue to exist. I didn't mean to suggest it wouldn't. PGP remains on the table for me. A Microsoft-only launch doesn't.
        woodruffw 4y ago
        There is a strict sense in which PGP does not remain on the table for you, because PyPI does not (and will not, on this developer’s clean conscience) ever support PGP for authentication :-) As said in adjacent threads, PyPI intends to add support for other OIDC providers once they give us the claims we need. Whether or not you choose to use it is ultimately up to you; normal API tokens will continue to work.
        benatkin 4y ago
        It still is, because I can have my CI use it to determine whether to publish a PyPI package. Nice try though. This is definitely a new low for Python. The main issue is just that it was a Microsoft-only launch. All the rest is just window dressing. It's a good reminder about the Pylance situation in Visual Studio Code. Microsoft tricked people into using closed source. https://ghuntley.com/fracture/ https://ghuntley.com/fracture/