I did. They’re interested. But which solution should I recommend?

Hence this question. So I can provide more useful information to the maintainer.

you don’t trust the Docker signing process, so getting a cryptographically signed image from there seems to fail your criteria.

If the image is signed by the developer, you don’t have to trust Docker (Hub) at all.

You could build a Debian base image in-house from scratch if you wanted to and limit your tools to Debian only signed packages.

But how would I verify the source code? It would have to be signed.

It doesn’t matter if it’s the release image layer that’s signed or the source (used to build the image layer) that’s signed. Either would need to be crypographically signed by the developer.

Ultimately you need to trust something.

Indeed. You need to trust something.

However, by using cryptographic signatures on release artifacts (eg container image layers), we 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.

You can pay for signed images from someone else

Can you tell me a bit more about this? Who are the major providers?

We do our pre-releases on CI runners for convenience. GitHub automatically kicks-off a build when we git push.

When it comes time to do a real release, we can just run the job locally on our build machines (this is easier thanks to docker). Because our builds are reproducible, we can just check that the hash matches on our local build and the one from the free GitHub CI runners. That way we don’t have to trust the infrastructure, but we can use it for free & easy iteration before our final release.

Yes, you have to trust someone.

However, by using cryptographic signatures on release artifacts (eg container image layers), we 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.

How could monitoring a firewall log protect you from a Publishing Infrastructure Compromise or MITM attack? It would just show the malicious image being downloaded from the expected source…

Because the hash comes from the same source as the image itself.

So if someone compromised the publishing infrastructure (or does a MITM attack), they can trivially maliciously modify the hash as easily as they can maliciously modify the image. It provides zero security to Publishing Infrastructure compromise.

A good historical example of this happening was when monero’s release infrastructure was comprimised. And here’s a great list of historically relevant cases where this happened:

• https://github.com/cncf/tag-security/tree/main/community/catalog/compromises

In the case of Monero, the users were able to verify that the release was malicious – because the cryptographic signature was invalid, and it was fixed very fast. If the user can only check checksums, they have literally no way to detect if the publishing infrastructure or a MITM attack is taking place.

With cryptographically signed images, you don’t need to trust Docker Hub nor the source code nor the base image. You just verify the signature that could only have been made from the developer. You trust the private key and the developer only, which significantly reduces the vector of attack (publishing infrastructure, X.509, docker hub admins, etc) by magnitudes.

Thanks. I assumed the client would figure it out automatically, but I guess that only works for links?

Is there a way to edit a post to indicate it’s a cross-post?

but how do you verify the sources of what you’re fetching?

Is it coming from an unsigned git repo? That seems equally vulnerable

but how do you verify the sources of what you’re fetching?

Is it coming from an unsigned git repo? That seems equally vulnerable…

Open-Source Software.

Can I install nix securely (eg with apt) to run inside the free CI runners provided by GitHub, GitLab, and Codeberg?