Michael Altfield

  • 4 Posts
  • 12 Comments
Joined 4 months ago
cake
Cake day: April 21st, 2026

help-circle
  • 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.



  • 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.