Comment on Replacement for Docker Content Trust (DCT)
moonpiedumplings@programming.dev 3 weeks ago
I think the most popular solution is locally building and registry.
Comment on Replacement for Docker Content Trust (DCT)
moonpiedumplings@programming.dev 3 weeks ago
I think the most popular solution is locally building and registry.
but how do you verify the sources of what you’re fetching?
Is it coming from an unsigned git repo? That seems equally vulnerable
HelloRoot@lemy.lol 3 weeks ago
How 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.
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.
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.
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.