5 ms·

>> but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manuall

>> but I don't think you actually want this: lots of large packages have multiple release managers (and contributors who come and go); you don't want to manually resolve each new human identity that appears for a package distribution. Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the *authors* remained the same, whoever they are. >> What most people actually want is a strong cryptographic attestation that the package distribution came from the same source as the thing hosting the source code Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. People *really* want to mitigate the risk of pypi infrastructure getting fully compromised, which is very likely, given how many eggs you keep in the same basket there. PGP signatures were the last ditch, not very convenient but also not as bad as they are painted. But from now on there will be not even that very little.

Beldin 3y ago
> that's what's your HTTPS certificate is for. Not really... That certificate doesn't go back in time. If a domain expires, an attacker could reregister it under their name and get a valid certificate. You'd be downloading from the right domain name with a valid HTTPS certificate, but you're not downloading from the same place as before.
- recursive 3y ago
  > That certificate doesn't go back in time. It does, kind of, if it's pinned.
  - dgrove 3y ago
    HKPK doesn't have a ton of adoption and only works in browsers. So this does nothing for curl, wget, pip
woodruffw 3y ago
> Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are. The point is that they don't remain the same. Assuming that they do is an operational error. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. HTTPS provides transport security, i.e. an authenticity relationship between you and GitHub's servers. It doesn't provide artifact authenticity for the source on that server, and cannot. That's what the comment above is referring to.
- zimmerfrei 3y ago
  > The point is that they don't remain the same. Assuming that they do is an operational error. How many projects are signing each release with a different PGP key each time? And what are the odds that such projects will actually correct their practices as soon as pip implements key verification and make the problems more visible? A lot I guess? It seems a lot of assumptions are being made... But it is a self-fulfilling prophecy: the more you hide, hamper, and cripple the signature metadata, the more people will misuse it (without knowing it), which leads to these articles that argue for more crippling because people are misusing it. The elephant in the room remains that pypi is a big target, and even though I highly appreciate the work done by maintainers (mostly volounteers?) I have a hard time believing they will always be able to keep skilled attackers away from its infra.
  - donaldstufft 3y ago
    Nobody at PyPI is opposed to package signing, and removing or minimizing the damage that compromised infrastructure can do. However, GPG is not a good tool to build those features on top of, and the vestigial support for GPG signing that PyPI had in no way aided the long term efforts to get proper, secure package signing into PyPI.
    - zzzeek 3y ago
      maybe your blog post can use a little extra line at the end that says, one of these three things: 1. "Nobody at Pypi is opposed to package signing, so long term here is the technology we want to use for this: XYZ..." 2. "Nobody at Pypi is opposed to package signing, however after years of discussion there seem to be no feasible ways of doing this, so going forward there are no plans to actually add package signing" (refer to @tptacek's post at https://news.ycombinator.com/item?id=36048373 https://news.ycombinator.com/item?id=36048373 which seems to claim there are many, IIRC) 3. "Nobody at Pypi is opposed to package signing, however we simply don't have the resources to implement any new approaches. We would require a grant of $X million dollars to hire people do do this (which would be using technology XYZ)" is there a choice 4?
Taywee 3y ago
> That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are The authors are often many people. You can have one person signing on behalf of all the others. PGP isn't going to tell you that the authors remained the same, only that the signer did (or that many people have access to the same private key and hopefully every one of them is completely trustworthy). PGP doesn't let you verify that the authors remained the same. Only the key. If you wanted to actually verify authors, you'd have to have all of them sign their own commits, and you'd have to validate every commit, not just the release, otherwise you're just back to trusting whoever holds the key. Many projects very regularly get new committers, too, so you'd have to validate many new signatures with every single update. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. No it's not. Your HTTPS certificate will not tell you "this PyPi package release is actually built and uploaded by the same person who controls the GitHub repository linked on the package page". PyPi hosts distributions. It frequently has source distributions, but it doesn't necessarily host "source code", which would usually mean the source repository. Even with that, it's Transport Layer Security, or a Secure Socket Layer. It does not authenticate anything other than the Socket/Transport itself. I'm fine with PGP, but most people don't really know how to use it. They add a key and think they're safe when it validates, but that only protects you if you already trust the key. PGP signing doesn't tell you "this is safe", just "this was signed by the person who has the private key for this public key", which isn't as useful without a lot of personal footwork or a trusted authority. PGP key signing parties were a thing for a reason. Using PGP properly requires either an initial leap of trust (importing your distro's keys and trusting what they trust), a lot of dilligence (personally verifying identities), or a small amount of dilligence with a good web of trust (you sign keys that you know are good, and so does everybody you know, so a lot of what you find online you can validate through your links).
- bombolo 3y ago
  The people in charge of doing a release, with the permissions to do so, are a much smaller subset than the authors. And PGP does support web of trust, so if the previous release guy trusts the new release guy… perhaps we could accept it as well.
crote 3y ago
>> knowing that the authors remained the same The problem is that "authors" is not a well-defined concept, and especially larger projects will have very regular author changes. Is the author the person who made the last commit? The person who uploaded it to PyPI? The person who is currently managing the project? What if it isn't a person but a company? >> that's what's your HTTPS certificate is for A lot of open source projects rely on untrusted third-party mirrors. The main server will just randomly redirect you to a mirror near you, so HTTPS certificates are pretty much useless because you are connecting to a third-party domain. They use signatures to prevent the mirror from doing weird stuff, and they guarantee that the mirror is serving the upstream content as-is.
- bombolo 3y ago
  > and especially larger projects will have very regular author changes We're not checking the signature of every commit, just of the release. It is usually 1 or 2 people who do releases.
- drexlspivey 3y ago
  The author is the person holding the release signing key
  - eesmith 3y ago
    "The"? Multiple people may hold the key. "Person"? The release could be part of an automated process.
- heyoni 3y ago
  But in this case we lose one way of defining authors.

Beldin 3y ago

> that's what's your HTTPS certificate is for. Not really... That certificate doesn't go back in time. If a domain expires, an attacker could reregister it under their name and get a valid certificate. You'd be downloading from the right domain name with a valid HTTPS certificate, but you're not downloading from the same place as before.

recursive 3y ago
> That certificate doesn't go back in time. It does, kind of, if it's pinned.
- dgrove 3y ago
  HKPK doesn't have a ton of adoption and only works in browsers. So this does nothing for curl, wget, pip

woodruffw 3y ago

> Nope, you assume wrong. That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are. The point is that they don't remain the same. Assuming that they do is an operational error. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. HTTPS provides transport security, i.e. an authenticity relationship between you and GitHub's servers. It doesn't provide artifact authenticity for the source on that server, and cannot. That's what the comment above is referring to.

zimmerfrei 3y ago
> The point is that they don't remain the same. Assuming that they do is an operational error. How many projects are signing each release with a different PGP key each time? And what are the odds that such projects will actually correct their practices as soon as pip implements key verification and make the problems more visible? A lot I guess? It seems a lot of assumptions are being made... But it is a self-fulfilling prophecy: the more you hide, hamper, and cripple the signature metadata, the more people will misuse it (without knowing it), which leads to these articles that argue for more crippling because people are misusing it. The elephant in the room remains that pypi is a big target, and even though I highly appreciate the work done by maintainers (mostly volounteers?) I have a hard time believing they will always be able to keep skilled attackers away from its infra.
- donaldstufft 3y ago
  Nobody at PyPI is opposed to package signing, and removing or minimizing the damage that compromised infrastructure can do. However, GPG is not a good tool to build those features on top of, and the vestigial support for GPG signing that PyPI had in no way aided the long term efforts to get proper, secure package signing into PyPI.
  - zzzeek 3y ago
    maybe your blog post can use a little extra line at the end that says, one of these three things: 1. "Nobody at Pypi is opposed to package signing, so long term here is the technology we want to use for this: XYZ..." 2. "Nobody at Pypi is opposed to package signing, however after years of discussion there seem to be no feasible ways of doing this, so going forward there are no plans to actually add package signing" (refer to @tptacek's post at https://news.ycombinator.com/item?id=36048373 https://news.ycombinator.com/item?id=36048373 which seems to claim there are many, IIRC) 3. "Nobody at Pypi is opposed to package signing, however we simply don't have the resources to implement any new approaches. We would require a grant of $X million dollars to hire people do do this (which would be using technology XYZ)" is there a choice 4?

Taywee 3y ago

> That's exactly what I (also) want, that is, knowing that the authors remained the same, whoever they are The authors are often many people. You can have one person signing on behalf of all the others. PGP isn't going to tell you that the authors remained the same, only that the signer did (or that many people have access to the same private key and hopefully every one of them is completely trustworthy). PGP doesn't let you verify that the authors remained the same. Only the key. If you wanted to actually verify authors, you'd have to have all of them sign their own commits, and you'd have to validate every commit, not just the release, otherwise you're just back to trusting whoever holds the key. Many projects very regularly get new committers, too, so you'd have to validate many new signatures with every single update. > Nope, nobody really needs more of that, since that's what's your HTTPS certificate is for. No it's not. Your HTTPS certificate will not tell you "this PyPi package release is actually built and uploaded by the same person who controls the GitHub repository linked on the package page". PyPi hosts distributions. It frequently has source distributions, but it doesn't necessarily host "source code", which would usually mean the source repository. Even with that, it's Transport Layer Security, or a Secure Socket Layer. It does not authenticate anything other than the Socket/Transport itself. I'm fine with PGP, but most people don't really know how to use it. They add a key and think they're safe when it validates, but that only protects you if you already trust the key. PGP signing doesn't tell you "this is safe", just "this was signed by the person who has the private key for this public key", which isn't as useful without a lot of personal footwork or a trusted authority. PGP key signing parties were a thing for a reason. Using PGP properly requires either an initial leap of trust (importing your distro's keys and trusting what they trust), a lot of dilligence (personally verifying identities), or a small amount of dilligence with a good web of trust (you sign keys that you know are good, and so does everybody you know, so a lot of what you find online you can validate through your links).

bombolo 3y ago
The people in charge of doing a release, with the permissions to do so, are a much smaller subset than the authors. And PGP does support web of trust, so if the previous release guy trusts the new release guy… perhaps we could accept it as well.

crote 3y ago

>> knowing that the authors remained the same The problem is that "authors" is not a well-defined concept, and especially larger projects will have very regular author changes. Is the author the person who made the last commit? The person who uploaded it to PyPI? The person who is currently managing the project? What if it isn't a person but a company? >> that's what's your HTTPS certificate is for A lot of open source projects rely on untrusted third-party mirrors. The main server will just randomly redirect you to a mirror near you, so HTTPS certificates are pretty much useless because you are connecting to a third-party domain. They use signatures to prevent the mirror from doing weird stuff, and they guarantee that the mirror is serving the upstream content as-is.

bombolo 3y ago
> and especially larger projects will have very regular author changes We're not checking the signature of every commit, just of the release. It is usually 1 or 2 people who do releases.
drexlspivey 3y ago
The author is the person holding the release signing key
- eesmith 3y ago
  "The"? Multiple people may hold the key. "Person"? The release could be part of an automated process.
heyoni 3y ago
But in this case we lose one way of defining authors.