.github

Consumers pin this repository by tag or commit SHA and move at their own pace; MAINTENANCE.md documents the versioned surface, what a release means and what may change between versions, and Renovate opens the upgrade pull request for every consumer automatically. https://github.com/monumental-archive/.github/blob/main/MAINTENANCE.md

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

No vulnerability report has been resolved in the last 12 months, so there is no reporter to credit. SECURITY.md commits to crediting reporters who do not request anonymity.

SECURITY.md documents the process end to end: private reporting through the repository's Security tab, acknowledgement within 14 days, what to expect afterwards, and the scope. https://github.com/monumental-archive/.github/blob/main/SECURITY.md

CONTRIBUTING.md names the gate as the coding standard in executable form, and the standards are specific per language: shellcheck for shell (with bash pinned by [task_config] shell because Ubuntu's sh is dash), actionlint and zizmor for workflow YAML, rumdl for Markdown, typos for spelling with the locale registers written down, and Conventional Commits with a 72-column subject ceiling. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

Automatically, in the gate: shellcheck, actionlint, zizmor, rumdl, typos and committed all run in mise run ci on every pull request, and fix:* siblings apply the machine-fixable subset. Style is never a review comment here.

The criterion's own N/A condition applies verbatim: no native binaries are generated. The only build in the project produces a source tarball (build-source-archive.yml), so there is no compiler or linker invocation for CC, CFLAGS, CXX, CXXFLAGS or LDFLAGS to be passed to or replaced.

Nothing is compiled, so there is no debugging information to preserve or strip. The project's only build produces a source tarball of text files (github-<version>.tar.gz, verified bit for bit under build_repeatable), and there is no end-user installation system that could strip anything.

The project's only build is single-pass and has no subdirectories to recurse into: build-source-archive.yml produces one source tarball in one step, so there are no cross-directory dependencies that a recursive build could order wrongly.

Building does occur, and it is verified bit for bit on every release. This repository publishes the source-archive class, so publish.yml runs build-source and repro-build-source as two independent builds and the repro gate compares their outputs (check source-archive) before anything is signed or attached — a mismatch fails the release. Verified on the live release: v1.22.2 ships github-1.22.2.tar.gz with checksums.txt, an SPDX SBOM and an attestations.intoto.jsonl bundle. A scheduled repro-check also re-verifies published history from cold.

Consumption is one convention and one command: mise trust && mise install brings the pinned toolchain, and a consuming repository adopts the governance by copying scaffold/ and calling the shared workflow by SHA. Nothing is installed system-wide and removal is deleting the pin.

There is no installation system for end users; tooling is installed into mise's own managed directory.

mise trust && mise install installs the entire pinned toolchain — every linter and tool the gate uses — from the lockfile, and mise run ci then runs exactly what CI runs. That is the whole developer setup. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

Machine-readable and pinned: mise/config.toml lists every tool with an exact version and mise.lock carries per-platform checksums; renovate.json drives automated updates; every uses: is pinned to a full commit SHA. https://github.com/monumental-archive/.github/blob/main/mise/config.toml

Continuously: Renovate and Dependabot open updates as new versions and advisories land, trivy runs in the gate, and the dependency track records VEX decisions keyed by package and version with coverage derived rather than asserted. https://github.com/monumental-archive/.github/blob/main/docs/dependency-track.md

Every reused component is identified by exact version in mise/config.toml with checksums in mise.lock, and updating is a Renovate pull request that the gate verifies — including a lint that fails when a version moves without its lock entry.

Dependencies are held at current versions by automated updates rather than allowed to drift, and actionlint fails the gate on deprecated GitHub Actions features, so obsolete interfaces surface as a red build rather than as rot.

gate.yml runs on every push and every pull request to main and reports success or failure as a required check; it self-applies the same reusable workflow this project publishes to the organisation. https://github.com/monumental-archive/.github/blob/main/.github/workflows/gate.yml

CONTRIBUTING.md, 'Requirements for acceptable contributions' item 3, is the formal written policy: a change that adds or changes behaviour adds the check that holds it - a test that fails without the change where a test suite exists, and a lint, audit task or workflow assertion in configuration and policy repositories. It is stated as policy: the gate's checks are the specification, and functionality nothing enforces is functionality the next change may silently remove. https://github.com/monumental-archive/.github/blob/main/CONTRIBUTING.md

The policy is stated in the documented instructions for change proposals themselves: CONTRIBUTING.md, item 3 of 'Requirements for acceptable contributions' - 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

Maximally strict by rule: CLAUDE.md requires tools enter the belt 'at maximum defensible enforcement', every task runs under set -euo pipefail, and linters are guarded only to skip where they genuinely do not apply — never to soften. Warnings fail the build.

The design principles are implemented, not just known: least privilege on every workflow permission block; an enforced capability boundary that forbids id-token: write in any workflow that runs caller-supplied code, with a lint that fails the build if it appears; no long-lived publishing credentials anywhere, only keyless trusted publishing and OIDC; and complete mediation of the supply chain by SHA-pinning every action with checksums and attestations.

Integrity everywhere is SHA-256 — per-platform checksums in mise.lock, image digests, attestation subjects — and signing is Sigstore's ECDSA P-256. No MD5 or SHA-1 is relied on as a security mechanism.

The project implements no cryptography and selects no algorithms; where cryptography is used it is Sigstore's and GitHub's, whose algorithm choices the project does not control.

The software stores no authentication credentials or private keys at all. Secrets live in GitHub environment and organisation secrets, never in files in the repository, and release signing uses ephemeral keys.

All network communication is HTTPS — GitHub APIs, tool downloads, registry publishing, transparency-log submission. No insecure protocol appears anywhere in the tree, and certificate verification is never disabled.

The software does not implement or configure TLS; it invokes tools (git, gh, curl) whose TLS versions are theirs.

Certificate verification is never disabled: there is no --insecure, -k, or GIT_SSL_NO_VERIFY anywhere in the tracked tree, so every HTTPS call made by the project verifies by default.

The software implements no TLS client of its own and sends no HTTP headers carrying private information.

Verified against the published release rather than asserted: v1.22.2 carries attestations.intoto.jsonl (the Sigstore evidence bundle) and checksums.txt alongside the archive and its SPDX SBOM. Signing is keyless — Sigstore/Fulcio with a Rekor transparency-log entry, no long-lived key — and docs/runbook.md documents verification from the consumer's position under 'Verifying as a consumer would'. https://github.com/monumental-archive/.github/releases/tag/v1.22.2

Release tags are annotated tag objects signed with Sigstore keyless signing by the release workflow, and the signature travels in the tag object itself: v1.25.0 carries a PKCS#7 SIGNED MESSAGE whose Fulcio certificate binds the signature to .github/workflows/release.yml@refs/heads/main in this repository - the same workflow identity the release evidence bundle is verified against. GitHub's UI reports these tags unverified with reason 'no_user' because it resolves signatures to GitHub accounts, and a keyless workflow identity is not an account; verification is against the certificate's subject alternative name, as described in signed_releases.

The shared workflows validate their inputs against allowlists rather than trusting callers: the artifact classes: input accepts only a known set, the publish stub's filename and shape are checked by lint:release-stub, and workflow inputs that would otherwise be interpolated into shell are guarded — zizmor fails the gate on template-injection patterns.

Least-privilege permissions on every workflow; an enforced capability boundary forbidding id-token: write in any workflow that runs caller-supplied code, checked by lint:capability-boundary in the gate; every action pinned to a full commit SHA with checksums and attestations; keyless publishing with no standing credentials; secret scanning with push protection enforced organisation-wide. Each mechanism is written up control by control, against the threat it answers, in docs/build-assessment.md. https://github.com/monumental-archive/.github/blob/main/docs/build-assessment.md

docs/release.md and docs/slsa-reference.md are the written assurance case, and docs/build-assessment.md and docs/source-assessment.md assess each claim against its evidence: the threat model (untrusted caller code reaching a privileged identity, unpinned supply-chain substitution, tampered artifacts), the countermeasures (the capability boundary, SHA pinning with checksums and attestations, keyless signing with transparency-log evidence), and an explicit record of what is NOT claimed. https://github.com/monumental-archive/.github/blob/main/docs/slsa-reference.md

zizmor is a vulnerability scanner specific to what this project produces — GitHub Actions workflows — covering template injection, excessive permissions, credential persistence and unpinned actions. CodeQL default setup is enforced organisation-wide and trivy adds misconfiguration and secret rules. All run in the gate on every pull request.

No memory-unsafe language is used in this repository; it is shell, YAML and configuration. The belt ships a cargo-fuzz pair for the Rust repositories that consume it.