Yes, you have to trust someone.
My point is that cryptographic signatures can reduce that risk from having to trust tens of thousands of people to just one person.
That’s a hugely meaningful reduction of risk.
Comment on Replacement for Docker Content Trust (DCT)
HelloRoot@lemy.lol 3 weeks agoHow do you verify that nobody is holding the original developer at gunpoint making them sign their software with their real key?
The point I’m trying to make: At some point, you have to trust something which you can not feasibly verify.
maltfield@slrpnk.net 3 weeks ago K3can@lemmy.radio 2 weeks ago
Sounds like you’re fairly invested in this, so why not reach out to the maintainer? It shouldn’t be difficult for them to offer a signed hash.
…But keep in mind that most images are built using base images and various other dependencies, which could all also be compromised. It might be better to eliminate docker entirely.
- maltfield@slrpnk.net 2 weeks ago
I did. They’re interested. But which solution should I recommend?
Hence this question. So I can provide more useful information to the maintainer.
moonpiedumplings@programming.dev 3 weeks ago
A common distribution method involves multi-party signing, that is, multiple developers use keys to sign off on reviewed changes.
Multiple developers review the changes, before signing the git commit after review. Then they build the package, either locally or on CI servers, but again, multiple parties/servers sign and review, doing a reproducible build to verify across machines.
In an ideal architecture, there is never a single point of failure. You would have to compromise the computers of multiple devs, or multiple build servers that are building signed reproducible builds, in order to do it.
Although in theory, you could compromise all of them. But it’s extremely difficult.