Files
SilverMetal/linux/build
SysAdmin 38ac4f8a96
Some checks failed
Build SilverMetal Linux ISO (reproducibility-gated) / build-and-verify (push) Failing after 15m34s
fix(linux/build): systemd-in-container build host (M1.1)
Run #4258 cleared the systemctl shim only to die two seconds later on
the *next* expectation derivative-maker has of a real systemd host:
its sources.list points at http://127.0.0.1:9977/debian (the approx
package-cache socket-activated by systemd) and apt-get update could
not reach the daemon because nothing was actually started by the
no-op shim:

    Err:1 http://127.0.0.1:9977/debian trixie InRelease
      Could not connect to 127.0.0.1:9977 (127.0.0.1).
      - connect (111: Connection refused)

Whack-a-mole'ing each service derivative-maker tries to start (approx
today, then journald, then systemd-logind, then who-knows-what
tomorrow) is going to keep failing for a while — derivative-maker is
fundamentally designed for a real systemd-managed Debian host. The
container pattern upstream itself ships
(linux/build/derivative-maker/docker/) runs systemd as PID 1 inside
the container; this commit adopts that approach.

Architecture:

  - PID 1 in the build container is now systemd. Upstream's vendored
    entrypoint.sh records the user-supplied command into
    /etc/docker-entrypoint-cmd, captures env into
    /etc/docker-entrypoint-env, masks irrelevant units, and execs
    systemd. systemd boots, docker-entrypoint.service runs the
    command, docker-entrypoint-stop.sh propagates the exit code via
    `systemctl exit <code>` so the container exits with the right
    status.

  - The four entrypoint files (entrypoint.sh,
    docker-entrypoint.service / .target, docker-entrypoint-stop.sh)
    are vendored at linux/build/docker/systemd-entrypoint/ rather
    than COPY'd from the submodule path — Docker build context can
    only reach below itself, and bumping is tracked in that dir's
    README.

  - Container runtime now requires --cgroupns=host, --tmpfs /run,
    --tmpfs /run/lock, and -v /sys/fs/cgroup:/sys/fs/cgroup:rw so
    systemd can manage cgroups properly. -t allocates a TTY,
    satisfying entrypoint.sh's `[ ! -t 0 ] && exit 1` check in CI
    where stdin is otherwise /dev/null.

  - User renamed builder → user (uid 1000, passwordless sudo) to
    match upstream's USER=user / HOME=/home/user convention. chown
    in build.sh now uses uid 1000:1000 so it's name-agnostic.

  - Image package list grew to match upstream's
    derivative-maker-docker-setup (sq stack + dbus + approx + the
    rest) plus our ISO toolchain (live-build / debootstrap / xorriso
    / squashfs-tools / etc.). Snapshot.debian.org pinning is
    preserved (same APT_SNAPSHOT_URL, two-phase install pattern).

Verified:

  Smoke test on 10.0.0.51 — `docker run --rm --privileged
  --cgroupns=host --tmpfs /run --tmpfs /run/lock -v /sys/fs/cgroup:...:rw
  -t <image> /bin/bash -c 'echo OK'` — booted systemd, ran the
  command via docker-entrypoint.service, captured the output, shut
  down filesystems and exited cleanly.

build.sh BUILDER_IMAGE pin → sha256:dc9dd29d…8811. Image rebuilt
natively on 10.0.0.51, pushed to docker-registry.silverlabs.uk.

The systemctl shim is removed by virtue of the Dockerfile rewrite —
real systemd makes it unnecessary. The previous "iter6 / iter7"
intermediate digests stay in the registry until we GC; the live one
is m1.1-iter8-systemd.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-07 12:06:47 +01:00
..

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:

  1. Checks out the commit with submodules.
  2. Runs build.sh twice in ${GITHUB_WORKSPACE}/build-{a,b}.
  3. Fails the run if the two ISO SHA256s differ, and uploads a diffoscope report as an artefact.
  4. On a tag push, attaches the verified ISO + SHA256SUMS + BUILD_INFO to 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:

  1. Provision a Debian 12 VM on the cluster with ≥ 8 vCPU, ≥ 16 GB RAM, ≥ 100 GB disk.
  2. Install Docker (apt install docker.io); ensure the runner user can run docker run --privileged.
  3. Register act_runner against git.silverlabs.uk with label silvermetal-builder.
  4. Pre-pull the builder image so the first reproducibility run isn't a cold start: docker pull docker-registry:5000/silvermetal-builder:latest
  5. 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-maker submodule — bump in its own PR, with a verification log showing two clean builds match.
  • snapshot-pin.env — same procedure.
  • Builder image (Dockerfile.builder digest) — rebuild, push, update BUILDER_IMAGE in build.sh, run reproducibility check, commit all four together.

What this milestone is not

  • No hardening overlay (M1.2)
  • No SilverBrowser/SilverVPN/SilverSync/SilverChat integration (M1.61.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.