How Rocky Linux's Peridot Build System Delivers Reproducible, Modular RHEL-Compatible Releases

The Problem: Reproducibility and Transparency in Enterprise Linux Builds

Enterprise Linux distributions need to guarantee that every binary shipped to users can be traced back to exact source inputs, compiler flags, and build environments. Traditional build pipelines like CBS (Community Build System) used by CentOS often obscure these details, making it hard to verify that a security patch rebuild matches the original or to audit supply-chain integrity. Rocky Linux replaced CBS with Peridot, a ground-up rewrite in Go that enforces reproducible builds, modular composes, and automatic SBOM generation — all driven by signed, machine-readable manifests.

Peridot's Pluggable Pipeline Architecture

Peridot separates the build process into independent, replaceable stages: source ingestion (lookaside cache, git), build execution (mock, Koji-compatible), and compose generation (pungi, lorax). Each stage is a plugin, so operators can swap implementations without rewriting the orchestrator. The pipeline is defined in YAML profiles that declare which modules, variants, and repositories to produce — BaseOS, AppStream, CRB, Plus, Extras, and variant ISOs (minimal, DVD, cloud, container) — all from a single run.

This modularity means the Release Engineering team can enable or disable entire module streams per compose, test alternative toolchains, or produce custom downstream rebuilds without forking the pipeline code.

Reproducible Builds via Signed BuildSet Manifests

Every Peridot build produces a BuildSet manifest — a JSON document signed by the release signing key — that pins every input: source RPM URLs and hashes, buildroot package NVRs (Name-Version-Release), compiler flags, container base image digests, and even the Peridot version itself. Because the manifest is self-contained, anyone with a compatible build environment can re-execute the pipeline and verify bit-for-bit identical output.

For example, the Rocky Linux 9.5 BaseOS compose publishes its manifest at https://dl.rockylinux.org/pub/rocky/9/compose/9.5/BaseOS/x86_64/os/.peridot-buildset.json. Inspecting this file reveals the exact golang version used to build Peridot, the mock configuration hash, and the list of every source RPM with its lookaside cache checksum.

Worked Example: Verifying a BuildSet Manifest

You can fetch and examine a live BuildSet manifest to see reproducibility data firsthand. Run the following on any machine with curl and jq installed (no elevated permissions needed):

curl -sL https://dl.rockylinux.org/pub/rocky/9/compose/9.5/BaseOS/x86_64/os/.peridot-buildset.json | jq '.buildSet | {pipelineVersion, modules: .modules | length, sources: .sources | length, buildroot: .buildroot.packages | length}'

Expected output shows the pipeline version, count of modules, source RPMs, and buildroot packages. The manifest also includes sbomRefs pointing to SPDX 2.3 documents generated by an integrated Syft scanner — one per built artifact — so downstream consumers get a complete software bill of materials without extra tooling.

Verification check: Compare the pipelineVersion in the manifest against the Peridot release tag on GitHub. If they match, the compose was produced by that exact Peridot version.

Promotion Gates and the 24-Hour Security SLA

Peridot implements a three-stage promotion workflow: testing → staging → release. When a security patch lands (e.g., a CVE fix for openssl), it enters the build queue, passes automated CI (rpminspect for RPM linting, openQA for installer and runtime tests), and is promoted to mirrors once the release key signs the BuildSet. Rocky's Release Engineering SOP targets a 24-hour SLA from patch availability to public mirror sync.

This gated promotion is visible in the compose directory structure: artifacts appear first under compose/9.5/BaseOS/x86_64/os/ with a .peridot-buildset.json referencing the testing tag, then move to staging and finally release as gates pass.

Trade-offs and Limitations

• Steep learning curve: Operating Peridot assumes fluency with RPM packaging, Koji concepts, pungi/lorax compose internals, and Go-based tooling. Teams without that background will struggle to customize or debug pipelines.
• Infrastructure demands: A full Peridot deployment needs build workers (mock/Koji), compose nodes (pungi/lorax), object storage for lookaside cache and artifacts, and a signing service. Small organizations typically consume Rocky's public mirrors rather than self-host.
• Evolving API: Minor Rocky releases (9.4 → 9.5) have introduced breaking changes to pipeline YAML schemas and promotion workflows. Pin Peridot versions in automation and test upgrades in staging before promoting.

Actionable Next Steps

1. Fetch a current .peridot-buildset.json from a Rocky compose mirror and inspect its sbomRefs to understand the SBOM structure.
2. Review the Peridot architecture docs at https://github.com/rocky-linux/peridot/tree/main/docs to evaluate whether the pluggable model fits your rebuild or downstream distribution needs.
3. If you maintain a RHEL-compatible derivative, consider adopting Peridot's BuildSet manifest format as your reproducibility contract — even if you keep your existing build tooling.

Peridot demonstrates that reproducible, auditable enterprise Linux builds are achievable with open tooling — but only if you invest in the expertise and infrastructure to run the pipeline end to end.