Skip to main content
SPRby Supernetworks

SPR 1.1.6: Sigstore Update Enforcement and Bit-Reproducible Containers

· 3 min read
Alex Radocea

Reproducible containers started shipping with v1.1.6.

Along with attestation enforcement during updates, this makes SPR updates safe to run. Users can verify containers match the source by reproducing the builds locally.

We first enabled sigstore enforcement in v1.1. Although we've been placing build attestation into Sigstore ledgers for awhile now, we first enabled enforcement with v1.1.

What the updater checks​

Before installing a container, the updater pulls the matching attestation out of Sigstore's public transparency log and verifies three claims: the workflow file that ran, the commit it ran against, and the runner that produced the image. If the attestation is missing, the update fails. If it points at a workflow we don't own, or a fork of our repo, the update fails. We don't keep a signing key anywhere. Sigstore issues a short-lived certificate to each workflow run through OIDC and writes the signature to a log that anyone can audit.

Stealing our GHCR token is no longer enough to push a backdoor to your router. An attacker would need to take over the GitHub Actions workflow itself, and leave a permanent entry in a log we don't control.

What "reproducible" means here​

Until this release, building SPR yourself produced a container that worked the same as ours but had a different digest. Timestamps and many subtle build changes would change the digest. The build environment is now pinned so that the same container hash reproduces from source, always.

To check it yourself:

git clone https://github.com/spr-networks/super
cd super
git checkout v1.1.6
./build_docker_compose.sh --load
export REMOTE_TAG=1.1.6
./base/scripts/verify-reproducibility.sh

verify-reproducibility.sh walks each published container's manifest, pulls the per-architecture config digest, and compares it to the image you just built. It prints OK when the layer hashes match.

Next up, adding an independent verifier​

Next we'd like to set up an independent verifier that signs the build reproductions as a second party. If this goes well, we will make updates look for this signature along with Github's. Transparency logs, reproducible builds, build attestation, and independent verifiers add confidence that the code we ship is the code that runs in a way that makes it exceedingly difficult for attackers to deploy malware.

A note on post quantum signatures​

We are waiting on for Github and the Sigstore community to deploy post quantum signatures. The previous 2035 timeline for PQ readiness is now set to 17 months from now to 2028.