Skip to content
Syn_OS Phoenix Syn_OS

Reproducible Builds (Forge)

tags: [general]

Forge is the supply-chain hardening release of Syn_OS. The v48 codename. Its job: make it possible for someone who does not trust the build infrastructure to independently verify that a Syn_OS ISO is the exact image it claims to be — and to lay the technical groundwork that a future FedRAMP Moderate, CMMC L2, and SOC2 audit engagement would draw evidence from. No such audit has been performed to date.

Reproducibility

Section titled “Reproducibility”

Forge is engineered for bit-for-bit reproducibility: rebuilding an ISO from the same commit on the same pipeline produces an identical digest. This is achieved via:

TechniqueWhat it fixes
SOURCE_DATE_EPOCH propagationAll file timestamps in the ISO derive from a single epoch value tracked in VERSION.epoch — no host-clock dependency
Deterministic mktempAll build temp dirs derive their name from a hash of the build inputs, not from the system random
Sorted tar and mksquashfsFile ordering inside archives is alphabetical, not filesystem-walk-order
Pacman snapshot pinThe Arch repository state is pinned to a fixed snapshot (Rec 30); pacman only sees that snapshot for the build
Locale archive verificationThe glibc locale archive is rebuilt deterministically (v43.2 fix)
Squashfs canonicalisationmksquashfs invoked with -no-fragments -reproducible -force-uid 0 -force-gid 0

The result: rebuilding from the same commit on the pipeline reproduces an identical SHA-256 digest. Cross-oracle verification — an independent second machine rebuilding the same commit and asserting the same digest — is the design target but is not live today: it lands once a second build oracle is provisioned (tracked, not yet scheduled).

Rebuild verifier

Section titled “Rebuild verifier”
Terminal window
synos-rebuild-verify.sh \
    --release v111.0.0 \
    --commit 8fee198a \
    --reference https://releases.synos-linux.pro/v111.0.0/synos-grimoire-v111.0.0.iso.sha256


# →   PASS — local digest matches reference
#     Sigstore Rekor entry verified
#     SLSA-3 provenance verified

The synos-rebuild-verify.sh script in fruit/iso/iso-build/ rebuilds a release from source and diffs the digest against the published reference. Run today, it verifies the pipeline is reproducible on the same oracle; it becomes a true cross-oracle verifier once a second oracle is online.

Cosign + Sigstore Rekor

Section titled “Cosign + Sigstore Rekor”

Every release artefact is signed with cosign and the signature is published to the Sigstore Rekor transparency log. Verification:

Terminal window
cosign verify-blob \
    --certificate synos-grimoire-v111.0.0.iso.cert \
    --signature  synos-grimoire-v111.0.0.iso.sig \
    --certificate-identity-regexp '.*@lumossolutions\.io$' \
    --certificate-oidc-issuer https://github.com/login/oauth \
    synos-grimoire-v111.0.0.iso


rekor-cli search --artifact synos-grimoire-v111.0.0.iso

Public Rekor index entries make every release independently verifiable forever, even if Lumos goes dark — the transparency log is operated by Sigstore, not by Lumos.

SLSA-3 provenance

Section titled “SLSA-3 provenance”

Forge wires slsa-github-generator into release-publish.yml, producing SLSA-3 build provenance for every release. Provenance attests:

  • The exact source commit
  • The build environment (runner image hash)
  • The build steps (.github/workflows/release-publish.yml)
  • The output artefact digests

The provenance is signed by Sigstore and stored alongside the release. SLSA-4 (two-witness) is deferred until the second build oracle is provisioned via the Stoneglass Ansible (queued behind second-oracle provisioning).

SBOM + dependency drift

Section titled “SBOM + dependency drift”

Every release ships a CycloneDX SBOM generated from the Cargo workspace + the Arch package set + the kernel module manifest. The build pipeline includes an SBOM drift detector (growth/development/scripts/monitoring/sbom-diff.sh) that flags newly-introduced transitive dependencies between releases.

The dependency advisory register lives at docs/security/SECURITY_ADVISORIES.md. Open advisories are triaged on a 7-day cadence.

Compliance posture

Section titled “Compliance posture”

Forge underpins the control mappings authored in v47 (Beachhead) + v59 (Doublecross). No formal audit or ATO has been performed — this is mapping work, not certification:

  • CMMC L2 — control map at fruit/distribution/legal/CMMC_L2_CONTROL_MAP.md
  • SOC2 — synos-attest-ledger exports the technical evidence a Type 2 engagement would draw on; no SOC2 audit has been run
  • FedRAMP Moderate — NIST SP 800-53 Rev 5 control map at fruit/distribution/legal/FEDRAMP_MODERATE_CONTROL_MAP.md, daily ConMon collector at growth/development/scripts/monitoring/fedramp-monitor.sh

Each control points to the technical mechanism that would satisfy it (e.g. SI-7 Software, Firmware, and Information Integrity points to the Forge cosign + SLSA-3 chain) — mapping, not attestation by an accredited third party.

Module signing

Section titled “Module signing”

Kernel modules are signed via cosign-attested keys (v41 Wave 9), applied during the sealed module-signing build stage. Signing material stays on the build oracle and is never included in the released image.

The signing chain is:

  1. Cosign-attested release key (federation root)
  2. → Module signing intermediate (rotated per release)
  3. → Per-module signature
  4. → MOK shim chain on SecureBoot-enabled installs (v41 Wave 9)

Reproducible kernel

Section titled “Reproducible kernel”

The Linux kernel build itself is reproducible:

  • LLVM/Clang (no GCC) — fewer non-determinism sources
  • KBUILD_BUILD_TIMESTAMP=$SOURCE_DATE_EPOCH
  • KBUILD_BUILD_HOST and KBUILD_BUILD_USER pinned to known values
  • vmlinuz is installed both into stage 04 and validated by stage 07a (accepts mkinitcpio exit-1 if the initramfs is real)

What Forge enables

Section titled “What Forge enables”
  • A federal customer’s ATO process would have a released ISO + Rekor entry + provenance + SBOM to start from — no ATO has been pursued or granted to date
  • A security researcher can independently rebuild and verify any release on their own hardware
  • A supply-chain attack on the oracle is detectable: an ISO whose Rekor signature is missing, or whose digest doesn’t match the rebuild, is by definition not a real release
  • A regulated buyer can pull the SOC2 / CMMC / FedRAMP control-mapping evidence directly from synos-attest-ledger without trusting Lumos’s attestation — evidence for a future audit, not proof one has occurred
Section titled “Related”