6 ms·

What are we switching to? Does Pypi support ECDSA?

woodruffw 3y ago
Just for disambiguation: ECDSA is a signing algorithm, not a protocol or toolkit like PGP. PGP can produce ECDSA signatures through an extension RFC, but it's not a core part of OpenPGP. There is no immediate replacement, because the overwhelming majority of packages never bothered to sign with PGP (and all evidence points to the overwhelming majority of signatures never being verified). In other words, this is much closer to removing "dead" code than to killing an active feature. Longer term, the plan is to integrate Sigstore[1]-based signatures. [1]: https://www.sigstore.dev/ https://www.sigstore.dev/
jossclimb 3y ago
sigstore I hope.
- aborsy 3y ago
  I’m not sure if I understand this correctly, but, this basically seems to be a CA, with SSO-type of proof of identity, short lived certificates and transparency logs? How an OIDC identity is obtained and secured is not treated. It brings useful organization to PKI, but the problem remains. You have to delegate trust to identity providers: Google, GitHub, etc. Keybase was interesting, but the project seems semi-dead.
  - woodruffw 3y ago
    > How an OIDC identity is obtained and secured is not treated. It brings useful organization to PKI, but the problem remains. You have to delegate trust to identity providers: Google, GitHub, etc. Yes, this is a fundamental (and, IMO, reasonable) assumption in Sigstore. The trust argument for large IdPs is that they (1) have the institutional ability and resources (like incident response) to maintain their service, (2) have strong incentives to maintain and improve the overall security of their providers (billions of accounts on the Internet are bound to SSO via Google, etc.), and (3) that any failures in those providers are already catastrophic, so reducing the number of moving and potentially failing parts is a net win in terms of security.
    - KRAKRISMOTT 3y ago
      How would someone publish a package without having to rely on institutional OAuth providers?
      - woodruffw 3y ago
        You can still publish a package without signing it; none of this is mandatory (or even implemented yet). IMO, one of the things that Sigstore will need to do to become a "serious" codesigning solution for OSS ecosystems is support one or more vendor-neutral IdPs: Sigstore itself is a Linux Foundation project and thus might be able to serve as the right venue for that, or it could be a CA/B-style affair where individual neutral IdPs can qualify for inclusion.
        dlor 3y ago
        I'd love to make this happen, but there aren't really any IDPs that meet this criteria yet. Happy to help get one going though!
        KRAKRISMOTT 3y ago
        You will run into this problem when developers from "fun" places like Russia and Iran try to sign packages since they are sanctioned by GitHub and other services. I am not sure about Python but quite a few high profile JavaScript libraries are by Russian engineers.
        arp242 3y ago
        > they are sanctioned by GitHub and other services They're sanctioned by various governments around the world, not GitHub. I think this is an important difference, because GitHub doesn't really have much choice in this.
        LtWorf 3y ago
        Ah yes. Let's give all of our personal information to USA… They are so trustworthy!
deleted 3y ago
[deleted]

Just for disambiguation: ECDSA is a signing algorithm, not a protocol or toolkit like PGP. PGP can produce ECDSA signatures through an extension RFC, but it's not a core part of OpenPGP. There is no immediate replacement, because the overwhelming majority of packages never bothered to sign with PGP (and all evidence points to the overwhelming majority of signatures never being verified). In other words, this is much closer to removing "dead" code than to killing an active feature. Longer term, the plan is to integrate Sigstore[1]-based signatures. [1]: https://www.sigstore.dev/ https://www.sigstore.dev/

jossclimb 3y ago

sigstore I hope.

aborsy 3y ago
I’m not sure if I understand this correctly, but, this basically seems to be a CA, with SSO-type of proof of identity, short lived certificates and transparency logs? How an OIDC identity is obtained and secured is not treated. It brings useful organization to PKI, but the problem remains. You have to delegate trust to identity providers: Google, GitHub, etc. Keybase was interesting, but the project seems semi-dead.
- woodruffw 3y ago
  > How an OIDC identity is obtained and secured is not treated. It brings useful organization to PKI, but the problem remains. You have to delegate trust to identity providers: Google, GitHub, etc. Yes, this is a fundamental (and, IMO, reasonable) assumption in Sigstore. The trust argument for large IdPs is that they (1) have the institutional ability and resources (like incident response) to maintain their service, (2) have strong incentives to maintain and improve the overall security of their providers (billions of accounts on the Internet are bound to SSO via Google, etc.), and (3) that any failures in those providers are already catastrophic, so reducing the number of moving and potentially failing parts is a net win in terms of security.
  - KRAKRISMOTT 3y ago
    How would someone publish a package without having to rely on institutional OAuth providers?
    - woodruffw 3y ago
      You can still publish a package without signing it; none of this is mandatory (or even implemented yet). IMO, one of the things that Sigstore will need to do to become a "serious" codesigning solution for OSS ecosystems is support one or more vendor-neutral IdPs: Sigstore itself is a Linux Foundation project and thus might be able to serve as the right venue for that, or it could be a CA/B-style affair where individual neutral IdPs can qualify for inclusion.
      - dlor 3y ago
        I'd love to make this happen, but there aren't really any IDPs that meet this criteria yet. Happy to help get one going though!
        KRAKRISMOTT 3y ago
        You will run into this problem when developers from "fun" places like Russia and Iran try to sign packages since they are sanctioned by GitHub and other services. I am not sure about Python but quite a few high profile JavaScript libraries are by Russian engineers.
        arp242 3y ago
        > they are sanctioned by GitHub and other services They're sanctioned by various governments around the world, not GitHub. I think this is an important difference, because GitHub doesn't really have much choice in this.
        LtWorf 3y ago
        Ah yes. Let's give all of our personal information to USA… They are so trustworthy!

deleted 3y ago

[deleted]