release-lab

Public git repository on GitHub. https://github.com/monumental-archive/release-lab

Repository on GitHub, which uses git. git can track the changes, who made them, and when they were made.

Every change lands as a pull request with its own commits; the repository contains the full development history, not only released states.

Repository on GitHub, which uses git. git is distributed.

Each release has a unique semantic version, tagged v<major>.<minor>.<patch> by the organisation's tag-minting GitHub App; tags are immutable under the organisation tag ruleset.

Semantic Versioning, derived from conventional commits by git-cliff.

Each release is identified by an immutable git tag (v*). https://github.com/monumental-archive/release-lab/tags

Every release carries generated release notes: CHANGELOG.md is produced by git-cliff from conventional commits and the same summary is attached to the GitHub release. https://github.com/monumental-archive/release-lab/releases

No release has fixed a publicly known run-time vulnerability in this software. Advisories against dependencies are handled visibly rather than silently: the release path refuses to publish with an undecided advisory in its SBOM — it blocked v0.19.1 for RUSTSEC-2021-0127 — and each release ships the resulting VEX decisions as an asset (release-lab-0.24.4.vex.openvex.json). https://github.com/monumental-archive/release-lab/releases

Bug reports are submitted through GitHub Issues using the organisation's issue forms; SUPPORT.md states where to ask. https://github.com/monumental-archive/release-lab/issues/new/choose

GitHub Issues, used for every individual issue. https://github.com/monumental-archive/release-lab/issues

The tracker is small and nothing on it is unanswered: three issues in total, two closed with the resolution recorded in the closing pull request, and one open — Renovate's dependency dashboard, which is a standing status page rather than a report awaiting a reply. https://github.com/monumental-archive/release-lab/issues?q=is%3Aissue

Enhancement requests are filed as issues, triaged and either closed with a linked pull request or closed with the reason recorded; the two closed issues here were resolved that way and none is left unanswered.

The issue tracker is public, permanently archived and searchable. https://github.com/monumental-archive/release-lab/issues?q=is%3Aissue

SECURITY.md publishes the process: private reporting through the repository's Security tab. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

GitHub private vulnerability reporting is enabled and is the documented channel in SECURITY.md, so reports stay private until an advisory is published. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

No vulnerability report has been received in the last 6 months, so there is no response time to report. SECURITY.md commits to acknowledgement within 14 days.

The software is Rust: cargo build --workspace builds it from source, and the release path builds the same tree into binaries, an OCI image, a wasm npm package and per-Postgres-major extension packages. The toolchain is pinned in mise.toml and installed by mise install. https://github.com/monumental-archive/release-lab/blob/main/mise.toml

cargo and rustc, at a version pinned in mise.toml (with wasm-pack, cargo-pgrx and cargo-auditable for the class-specific builds) — the standard build tooling of the language.

The entire toolchain is FLOSS: rustc, cargo, wasm-pack, cargo-pgrx, cargo-auditable, cargo-fuzz and mise itself.

mise run ci is the automated suite and it is what CI runs: it collects the organisation's lint belt, runs cargo test --workspace --locked, and enforces the committed coverage floor with cargo-llvm-cov. Identical locally and in the cloud, from the same lockfile. https://github.com/monumental-archive/release-lab/blob/main/mise.toml

mise run ci — one command, identical locally and in CI. https://github.com/monumental-archive/release-lab/blob/main/README.md

The suite covers most of the code it measures: 87.10% line coverage over the crates tested on the gate runner, enforced by the coverage ratchet in mise run ci. Beyond unit tests, every version exercises the whole repository end to end — four artefact classes across five Postgres majors, each with a smoke test — because that release path is what this repository exists to prove.

gate.yml runs the full gate on every push and pull request to main, calling the organisation's shared reusable workflow across a repository boundary. https://github.com/monumental-archive/release-lab/blob/main/.github/workflows/gate.yml

CONTRIBUTING.md item 3 of 'Requirements for acceptable contributions' is the written policy: a change that adds or changes behaviour adds the check that holds it, and a bug fix adds the case that reproduced the bug. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

New fixture behaviour arrives with its test: the parse-marker fuzz target and its committed corpus landed with the code they exercise, and each new artifact class landed with the smoke test the release path runs against it (scripts/image-smoke.sh, scripts/binary-smoke.sh).

The policy is stated in the contributor-facing documentation itself: CONTRIBUTING.md, item 3 of 'Requirements for acceptable contributions'. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

rustc's warning set is on for every build and cargo test --workspace --locked surfaces it, and the shared lint belt runs shellcheck, actionlint, zizmor, typos, taplo and rumdl over every tracked file, where a warning is a failure — the gate exits non-zero and a red gate cannot merge.

The tree builds and tests warning-free; the gate is red on any belt warning and no change merges red.

The security architecture this repository runs under is designed and documented in the governance repository: least privilege on every workflow permission block, an explicit capability boundary forbidding id-token: write in any workflow that runs caller-supplied code, keyless trusted publishing instead of long-lived tokens, and SLSA Build/Source/Dependency levels claimed only where evidence exists. This repository is where those controls are exercised first. https://github.com/monumental-archive/.github/blob/main/docs/slsa-reference.md

The error classes specific to this software are documented and defended: credential exfiltration through untrusted workflow input (zizmor and the capability-boundary lint), unpinned actions and supply-chain substitution (every uses: pinned to a full commit SHA, every tool checksummed), and unsafe input handling in the fixture crates (a libFuzzer target with a committed corpus). The README's table of what proving here has caught is the running record. https://github.com/monumental-archive/release-lab/blob/main/README.md

The fixture crates implement no cryptography of their own. Where the release path relies on cryptography it uses published, expert-reviewed mechanisms: Sigstore (Fulcio certificates, Rekor transparency log), GitHub artifact attestations, npm provenance and SHA-256 digests.

Cryptographic operations are delegated to software built for the purpose — Sigstore/cosign, GitHub's attestation tooling and git — never reimplemented here.

All cryptography relied on is FLOSS: Sigstore, cosign and git.

The software selects no keylengths. Release signing uses ephemeral Sigstore keys with Fulcio-issued certificates, and transport keys belong to GitHub and the registries.

No broken algorithm is depended on for security: artifact integrity is SHA-256 (checksums.txt, image digests, attestation subjects, mise.lock) and signing is Sigstore's ECDSA P-256.

Integrity everywhere is SHA-256 and signing is Sigstore's ECDSA P-256. No MD5 or SHA-1 is relied on as a security mechanism.

The fixture crates implement no key agreement protocol; they are a library, a CLI, a wasm package and a Postgres extension, none of them a network service.

The software stores no passwords and authenticates no external users.

The software generates no cryptographic keys or nonces; release signing keys are generated by Sigstore.

Everything is delivered over HTTPS by GitHub, GHCR and npm. Beyond transport, every dependency is pinned: Cargo.lock for crates, mise.lock with per-platform checksums for tools, full commit SHAs for every uses:, and image bases by digest.

Checksums are not fetched over http at use time: they travel with the source in Cargo.lock and mise.lock, and every published release carries Sigstore evidence bundles and GitHub artifact attestations that a consumer can verify against the digest.

There are no known unpatched vulnerabilities of medium or higher severity. cargo-deny and osv-scanner run in the gate, dependency-review runs on every pull request, Renovate and Dependabot open updates continuously, and the release path refuses to publish with an undecided advisory in the SBOM — RUSTSEC-2021-0127 was decided and published as a VEX statement rather than left unanswered.

Critical vulnerabilities are fixed as they are identified; dependency updates are automated and the release gate blocks on the dependency checks.

No credential is committed. GitHub secret scanning with push protection is enforced by the organisation security configuration, trivy's secret rules run in the gate, and the design avoids long-lived credentials entirely: publishing is keyless via trusted publishing and OIDC.

CodeQL default setup is enforced organisation-wide, and the gate runs cargo-deny and osv-scanner over the lockfile, shellcheck over shell, actionlint and zizmor over every workflow, and trivy over configuration — on every pull request, before any release.

CodeQL is enforced organisation-wide for the languages in this repository, cargo-deny and osv-scanner match the dependency graph against advisory databases, and zizmor is a scanner specific to the other artefact here — GitHub Actions workflows — covering template injection, excessive permissions, credential persistence and unpinned actions.

Findings are fixed before merge — the gate blocks the pull request, and the organisation's static-analysis policy sets the remediation threshold at zero. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

On every commit: the gate runs on every pull request and every push to main, with a scheduled Monday audit re-running the network-dependent checks and a Thursday cold rebuild of the latest published release.

Fuzzing runs, and it satisfies this criterion's own definition of a tool that varies its inputs: cargo-fuzz drives libFuzzer against the parse_marker target with a committed in-tree corpus. The deterministic half (lint:fuzz-build) is in the gate on every pull request so a target that stops compiling fails the build; the time-bound half (audit:fuzz) runs the targets on the scheduled audit and fails with a reproducer path on any crash or panic. https://github.com/monumental-archive/release-lab/tree/main/fuzz

No memory-unsafe language is used: the crates are safe Rust with no unsafe blocks in the tracked sources, which is why the fuzz targets build with --sanitizer none on the pinned stable toolchain — in safe Rust the failure class libFuzzer surfaces is the panic, not the buffer overwrite.

The fuzz and test builds are debug builds: debug_assertions and integer overflow checks are on, so assertion failures and overflows abort rather than pass silently.

No fuzzing finding is outstanding. A crash or panic fails audit:fuzz with the reproducer path in the log, and interesting inputs are committed to the in-tree corpus so the case stays covered.