5 ms·

> It would be nice if package managers would not only support 2FA, but make it available via metadata the uploader and whether the uploader used 2FA. How would

> It would be nice if package managers would not only support 2FA, but make it available via metadata the uploader and whether the uploader used 2FA. How would this work when the package manager can be run by anyone? 2FA is an authentication method (akin to asking for a password, albeit a special one). It's not a digital signature.

javagram 7y ago
It would work if you have a centralized registry with a centralized authentication (like npm does, or maven central). You’re correct that it’s not a digital signature. You have to be able to trust the registry (whose communications to you are signed, via HTTPS).
- eru 7y ago
  That would be pretty annoying. The signatures are an end-to-end thing. As long as you can trust the signer at time of signing, you can trust the package. No matter what happened to that package in the meantime, or what shady people were in charge of transmitting it to you. Be that five minutes after uploading or fifty years. 2FA and HTTPS only do anything extra on top of that for you, if you trust the whole chain of transmission at all times, and all custodians of the data. Adding 2FA and HTTPS might still be a good idea as a second line of defense. But it's not a replacement for signed packages.
  - javagram 7y ago
    If the signer puts their key on a build server and that build server is hacked, then the signing is worthless. (Although, having written this, I suppose people would just put their TOTP secret on the build server also) With a centralized registry model I already trust the registry anyway. It’s not like I’m typically going out and verifying people’s keys by emailing them to check what their real key should be or whatever.
    - eru 7y ago
      You are right about some of the complications. You'd want https://en.wikipedia.org/wiki/Reproducible_builds https://en.wikipedia.org/wiki/Reproducible_builds for a clear relation between source and artefacts. Then build-server hacking would be slightly less problematic: at least anyone would be able to check whether the server had produced any compromised builds. And you could have multiple independent entities producing builds in parallel for your open source projects that need to agree. So a hacker would need to take control of all of them. (You don't need to figure out byzantine fault tolerance or something like that: if there's any discrepancy, sound the alarm bells and have humans investigate.) Every build server would sign their artefacts, but the signature would just certify that some specific sources compile to some specific artefact. Not that the sources are trustworthy. Now you need to trust: the author of the sources of the packages at the times of signing, and that at least one of the all agreeing build servers that you ever collected signatures from for the package was not compromised at the time of signing. That signing build server doesn't even have to be the same server that build your binary packages, the latter could be run by Satan for all you care. Yes, in practice you will trust a central registry. The benefit of the signature model is that you don't have to trust the whole chain of provenance, but only at specific points in time.

javagram 7y ago

It would work if you have a centralized registry with a centralized authentication (like npm does, or maven central). You’re correct that it’s not a digital signature. You have to be able to trust the registry (whose communications to you are signed, via HTTPS).

eru 7y ago
That would be pretty annoying. The signatures are an end-to-end thing. As long as you can trust the signer at time of signing, you can trust the package. No matter what happened to that package in the meantime, or what shady people were in charge of transmitting it to you. Be that five minutes after uploading or fifty years. 2FA and HTTPS only do anything extra on top of that for you, if you trust the whole chain of transmission at all times, and all custodians of the data. Adding 2FA and HTTPS might still be a good idea as a second line of defense. But it's not a replacement for signed packages.
- javagram 7y ago
  If the signer puts their key on a build server and that build server is hacked, then the signing is worthless. (Although, having written this, I suppose people would just put their TOTP secret on the build server also) With a centralized registry model I already trust the registry anyway. It’s not like I’m typically going out and verifying people’s keys by emailing them to check what their real key should be or whatever.
  - eru 7y ago
    You are right about some of the complications. You'd want https://en.wikipedia.org/wiki/Reproducible_builds https://en.wikipedia.org/wiki/Reproducible_builds for a clear relation between source and artefacts. Then build-server hacking would be slightly less problematic: at least anyone would be able to check whether the server had produced any compromised builds. And you could have multiple independent entities producing builds in parallel for your open source projects that need to agree. So a hacker would need to take control of all of them. (You don't need to figure out byzantine fault tolerance or something like that: if there's any discrepancy, sound the alarm bells and have humans investigate.) Every build server would sign their artefacts, but the signature would just certify that some specific sources compile to some specific artefact. Not that the sources are trustworthy. Now you need to trust: the author of the sources of the packages at the times of signing, and that at least one of the all agreeing build servers that you ever collected signatures from for the package was not compromised at the time of signing. That signing build server doesn't even have to be the same server that build your binary packages, the latter could be run by Satan for all you care. Yes, in practice you will trust a central registry. The benefit of the signature model is that you don't have to trust the whole chain of provenance, but only at specific points in time.