Skip to content
Syn_OS Phoenix Syn_OS

Reproducible Builds (Forge)

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 chain that verification into FedRAMP Moderate, CMMC L2, and SOC2 evidence.

Reproducibility

Section titled “Reproducibility”

Forge guarantees bit-for-bit reproducibility when an ISO is rebuilt on a different oracle node. 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: two oracle nodes, building from the same commit, produce ISOs whose SHA-256 digests are identical.

Cross-oracle verifier

Section titled “Cross-oracle verifier”
Terminal window
# on a second oracle:
synos-rebuild-verify.sh \
    --release v60.0.0 \
    --commit 636e1aa0 \
    --reference https://releases.synos-linux.pro/v60.0.0/synos-master-v60.0.0.iso.sha256


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

The synos-rebuild-verify.sh script in growth/development/scripts/iso-build/ is the canonical cross-oracle verification entry point.

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-master-v60.0.0.iso.cert \
    --signature  synos-master-v60.0.0.iso.sig \
    --certificate-identity-regexp '.*@lumossolutions\.io$' \
    --certificate-oidc-issuer https://github.com/login/oauth \
    synos-master-v60.0.0.iso


rekor-cli search --artifact synos-master-v60.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 (one of the v60 external blockers).

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 v60 readiness check 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 compliance evidence shipped in v47 (Beachhead) + v59 (Doublecross):

  • CMMC L2 — control map at fruit/distribution/legal/CMMC_L2_CONTROL_MAP.md
  • SOC2 — exporters generate Type 2 evidence packs from synos-attest-ledger
  • 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 satisfies it (e.g. SI-7 Software, Firmware, and Information Integrity points to the Forge cosign + SLSA-3 chain).

Module signing

Section titled “Module signing”

Kernel modules are signed via cosign-attested keys (v41 Wave 9). The v43.2 fix matrix added sudo escalation for the openssl-based module signer when the signing key is root-readable — closing a build failure that hit on certain oracle configurations.

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 (which now accepts mkinitcpio exit-1 if the initramfs is real — v60 fix)

What Forge enables

Section titled “What Forge enables”
  • A federal customer can hand the released ISO + Rekor entry + provenance + SBOM to their ATO process
  • 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 cross-oracle rebuild, is by definition not a real release
  • A regulated buyer can pull SOC2 / CMMC / FedRAMP evidence directly from synos-attest-ledger without trusting Lumos’s attestation
Section titled “Related”