SysAdmin
c9e67d8b47
Run #4273 confirmed two things: 1. The reproducibility gate works end-to-end. Both builds produced ISOs (1077194752 vs 1077202944 bytes — 8 KiB delta, exactly one squashfs block worth of compressed-payload drift) and the compare step caught it. 2. diffoscope, run on the whole 1 GB ISO inside the silvermetal-builder container, gets OOM-killed before producing any output: diagnose-divergence.sh: line 44: 13 Killed diffoscope --max-report-size 100000000 --html ... --text ... A.iso B.iso The host has 19 GiB free, but diffoscope's full recursion through ISO -> squashfs -> ~thousands of inner files needs more memory than that for a 1 GB image. Setting --max-report-size only caps the output, not the working-set. Rewrite diagnose-divergence.sh to do staged, cheap-to-expensive analysis: 1. sha256 + sizes (always) 2. xorriso TOC of both ISOs (every node: mode/size/mtime/path) -> diff 3. Pull just live/filesystem.squashfs out of each ISO, sha256 it + `unsquashfs -ll` it, diff the listings — this is where the per-file-size signal lives. 4. Targeted diffoscope on the squashfs payload only, with --max-container-depth 2 + --max-text-report-size 5MB + --no-html + a 10-minute timeout. Bounded enough to finish without the OOM. Drops `set -e` — every step `|| true`s itself so we get partial output even when one stage fails. Workflow tail-into-log step now prints the new staged outputs: * toc-diff.txt — what changed at the ISO level * sqfs-ls-diff.txt — which inner files have different sizes/mtimes * sqfs-diff.txt — diffoscope on the squashfs only * squashfs-sha256.txt * iso-header-cmp.txt — first-8KB cmp -l for header-level drift * sizes.txt / sha256.txt / checklist.md as before Should land us a focused list of "these N files inside the squashfs have different bytes" — that's what we need to find what's leaking non-determinism into the build. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
SilverMetal Linux — reproducible ISO build pipeline
Milestone: Phase 1 / M1.1 — Kicksecure fork builds reproducibly. Exit criterion: two clean builds of the same commit produce a byte-identical SHA256.
This directory holds everything that turns a SilverMetal commit into a SilverMetal Linux ISO. M1.1 ships only the base (un-hardened) Kicksecure derivative. Hardening overlay, kernel swap, AppArmor profiles, etc. land in M1.2+ and must not be added here in the M1.1 PR.
Layout
linux/build/
├── README.md (this file)
├── derivative-maker/ git submodule -> Kicksecure/derivative-maker
├── config/
│ ├── silvermetal-base.conf derivative selection + branding
│ ├── snapshot-pin.env pinned snapshot.debian.org timestamp
│ └── source-date-epoch.env optional SOURCE_DATE_EPOCH override
├── docker/
│ └── Dockerfile.builder pinned debian:bookworm-slim builder image
└── scripts/
├── build.sh wrapper: container run -> derivative-maker
├── verify-reproducibility.sh build twice, compare SHA256
└── diagnose-divergence.sh diffoscope on mismatch
How reproducibility is achieved
The same levers any deterministic Debian build relies on, stacked together:
| Lever | Where it lives |
|---|---|
Pinned snapshot.debian.org mirror |
config/snapshot-pin.env |
SOURCE_DATE_EPOCH from commit time |
scripts/build.sh (auto) |
| Pinned builder image (by digest) | docker/Dockerfile.builder + BUILDER_IMAGE |
Deterministic mksquashfs flags |
MKSQUASHFS_OPTIONS in base conf |
| Pinned upstream toolchain | derivative-maker/ submodule |
LC_ALL=C.UTF-8, TZ=UTC |
scripts/build.sh |
diffoscope is the diagnostic tool used by diagnose-divergence.sh; the gate itself is plain sha256sum.
Reproduce a release locally
Procedure mirrors
docs/trust-model.md§ Reproducible builds.
Prerequisites: a Linux host (or WSL2) with Docker, ~30 GB free disk, ~8 GB RAM.
# 1. Clone the repo at the release tag.
git clone --recurse-submodules https://git.silverlabs.uk/SilverLABS/SilverMetal.git
cd SilverMetal
git checkout v1.1.0 # whichever release you want to verify
# 2. Build twice and compare. ~60-90 minutes per build.
linux/build/scripts/verify-reproducibility.sh
# 3. Compare against the published release.
sha256sum -c <(curl -fsSL https://git.silverlabs.uk/SilverLABS/SilverMetal/releases/download/v1.1.0/SHA256SUMS)
Mismatch with the published artefact = supply-chain anomaly. Report channel: security@silverlabs.uk.
Build once (no reproducibility check)
linux/build/scripts/build.sh
# Output lands in linux/build/output/<short-sha>/
The wrapper requires BUILDER_IMAGE to be pinned by digest. Local dev that hasn't built and pushed an image yet should override:
BUILDER_IMAGE=docker-registry:5000/silvermetal-builder@sha256:<digest> \
linux/build/scripts/build.sh
Gitea Actions
The CI workflow (.gitea/workflows/build-iso-linux.yaml) is the authority for "did this commit build reproducibly?". It:
- Checks out the commit with submodules.
- Runs
build.shtwice in${GITHUB_WORKSPACE}/build-{a,b}. - Fails the run if the two ISO SHA256s differ, and uploads a
diffoscopereport as an artefact. - On a tag push, attaches the verified ISO +
SHA256SUMS+BUILD_INFOto a Gitea release.
Self-hosted runner setup
The workflow runs on runs-on: silvermetal-builder, a self-hosted, privileged-capable Gitea Actions runner. Create it before merging the workflow:
- Provision a Debian 12 VM on the cluster with ≥ 8 vCPU, ≥ 16 GB RAM, ≥ 100 GB disk.
- Install Docker (
apt install docker.io); ensure the runner user can rundocker run --privileged. - Register
act_runneragainstgit.silverlabs.ukwith labelsilvermetal-builder. - Pre-pull the builder image so the first reproducibility run isn't a cold start:
docker pull docker-registry:5000/silvermetal-builder:latest - Cache the apt snapshot in a Docker volume to avoid throttling:
docker volume create silvermetal-apt-cache
The runner host name must not leak into ISO content. LC_ALL=C.UTF-8 and a constant TZ in the wrapper guard against that, but spot-check with diagnose-divergence.sh.
Bumping pinned inputs
Each of these is a deliberate, reviewed action — never automate:
derivative-makersubmodule — bump in its own PR, with a verification log showing two clean builds match.snapshot-pin.env— same procedure.- Builder image (
Dockerfile.builder) — edit and commit. CI'sbuilder-imagejob rebuilds, pushes, and feeds the new digest tobuild-and-verifyautomatically; no manualdocker build/docker pushstep. The hardcodedBUILDER_IMAGEdigest fallback inbuild.shis for local/offline rebuilds only — bump it opportunistically after any merged Dockerfile change so non-CIbuild.shkeeps working at that commit.
What this milestone is not
- No hardening overlay (M1.2)
- No SilverBrowser/SilverVPN/SilverSync/SilverChat integration (M1.6–1.9)
- No installer branding (M1.5)
- No update server (M1.10)
- No SBOM publication (M1.11)
- No signing ceremony / MOK / Secure Boot wiring (separate milestone)
If a change to this directory expands its scope into one of those, push back — the M1.1 gate is intentionally narrow.