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 22 hours 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 21 hours ago 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.
moonpiedumplings@programming.dev 20 hours 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.