monumental-archive-db

Every workflow declares permissions: contents: read at the top level, so a job that specifies nothing inherits read-only. Elevated scopes are granted per job and annotated inline with the reason — packages: write only on the jobs that push, id-token: write only where Sigstore needs it.

Every published image carries a unique identifier by construction: its immutable OCI manifest digest, plus a :sha-<commit> tag giving per-commit traceability. A tag-immutability repository ruleset prevents any tag from moving, and consumers pin digests. The project deliberately has no semantic version surface — its version is the postgres major plus three extension pins — but uniqueness is absolute rather than merely conventional.

The project creates no official releases. It is a rolling publisher: fixes land on main and a new digest publishes, with no version tags and no maintained back-branches, stated as a deliberate exclusion in https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/roadmap.md. What exists instead: every published digest is traceable to exactly one commit through its :sha-<commit> tag, the history is conventional-commit formatted so the functional and security changes between any two digests are readable with git log, and security modifications specifically are published as GitHub security advisories naming the fixing digest.

Dependencies are ingested entirely through standardized tooling: apt from PGDG and Debian for the extensions, the OCI registry protocol for both digest-pinned images, and mise for the development toolchain. Nothing is fetched with ad-hoc curl-to-shell, and there is no vendored or hand-copied dependency anywhere.

An OCI manifest is precisely a signed manifest containing each asset's cryptographic hash: it lists every layer by sha256 digest, and the manifest itself is cosign-signed keylessly with this repository's publish workflow on main as the certificate identity, anchored through @refs/heads/main$. The pipeline then runs cosign verify against that exact identity immediately after signing. SPDX SBOM and provenance (mode=max) attestations accompany it. https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#verifying-what-you-pulled

Selection is governed: the image is postgres plus exactly three extensions because the consuming archive needs those three, and a fourth is a recorded governance decision rather than a routine addition, with the bar stated in https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/roadmap.md. Obtaining is documented in https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/decisions/0001-own-the-installation.md, which explains why PostGIS and pgaudit are installed here from PGDG rather than inherited. Tracking is the Renovate pin convention in https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#coding-standard — apt versions in ARG *_VERSION lines with a # renovate: comment above them, because an inline version would silently lose coverage.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#development-quick-start — clone, mise install (which installs the pinned toolchain and the git hooks), then task ci for the full gate or task build for the image alone. The only prerequisite not installed by mise is Docker or a compatible engine, which is stated explicitly.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/GOVERNANCE.md#roles-and-responsibilities names the single maintainer who holds access to sensitive resources, and https://github.com/CarlAllenn/monumental-archive-db/blob/main/GOVERNANCE.md#access-continuity is explicit about what that access consists of — notably that no long-lived tokens or signing keys exist to hold, because GHCR uses the run's own token and signing is keyless.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/GOVERNANCE.md#roles-and-responsibilities — maintainer and contributor roles with what each owns, plus the decision model and how it would evolve if the project gained regular contributors.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#requirements-for-an-acceptable-contribution — one pull request per issue, conventional commits, signed commits, DCO sign-off, a green gate, respect for the decision register, and new words in .codespellrc rather than a lint bypass.

Direct pushes to main are blocked by the main-protection ruleset, so every commit arrives through a pull request, and the full gate runs as required status checks that must pass before merge. The same tasks run locally on every commit through the lefthook hooks, so the checks are not first encountered in CI.

Every pull request runs task ci, which includes the smoke test — booting the built image and asserting the extensions actually load via pg_get_loaded_modules(). The publish pipeline runs the same suite per-architecture on native amd64 and arm64 runners, and again against the published bytes pulled back from the registry by digest. https://github.com/CarlAllenn/monumental-archive-db/actions

https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md documents the actors and actions: the five trust boundaries (publish, build-stage, apt, in-image privilege, registry identity), the four supply-chain substitution points an adversary could target, what crosses each boundary and by what mechanism, and what is explicitly out of scope. https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/decisions/0001-own-the-installation.md carries the load-bearing architectural decision behind the design.

The released asset's external interfaces are the PostgreSQL wire protocol on 5432, the environment-variable contract inherited unchanged from the official postgres image, the PGDATA volume, and the three extensions the image adds. All are documented in https://github.com/CarlAllenn/monumental-archive-db#readme, together with the baked server configuration (shared_preload_libraries and wal_level=logical) that changes behaviour relative to a stock postgres image — which is the part a consumer could not infer from upstream documentation.

Two documents, deliberately different in kind. https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md is the standing assessment: threat model in order of exposure, the four substitution points, and a table of weakness classes with countermeasures and evidence. https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/security-review-2026.md is a dated assessment performed 2026-08-09 against a specific commit, with five findings and a disposition for each — including two that resulted in fixes.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#reporting-a-vulnerability sets out coordinated disclosure with explicit timeframes: acknowledgement within 7 days, a triage verdict (accepted, out of scope, or upstream) within 14, then a fix republished as a new digest with that digest named in the published advisory. Reporters are credited. The scope boundary between this image and its upstreams is stated precisely so a reporter knows where to send what.

GitHub private vulnerability reporting is enabled and linked directly: https://github.com/CarlAllenn/monumental-archive-db/security/advisories/new — the report stays private until a fix ships. An email fallback to the maintainer address on the commits is documented for anyone who cannot use it.

Vulnerabilities are published as GitHub security advisories on https://github.com/CarlAllenn/monumental-archive-db/security/advisories, with the fixing digest named in each, per the commitment in https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#what-to-expect. Package-level CVE state is additionally public on every run: the publish workflow runs a report-only trivy scan so each published digest has its scan output on the run log.