monumental-archive-db

The supported version is the latest published digest, and it is republished weekly by a scheduled cache-free rebuild. The upgrade path is a digest bump, which is what Renovate is for — the :main tag exists so Renovate has something to resolve against. Because consumers pin digests, nothing the project does can change an image already pulled, so an upgrade is always a deliberate, reversible act. https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#supported-versions

https://github.com/CarlAllenn/monumental-archive-db/issues

Reporters are credited on the published advisory; this is stated in the reporting section itself as a reason to use private advisories. https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#reporting-a-vulnerability

https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#what-to-expect — acknowledgement within 7 days, triage verdict within 14, accepted defects fixed and republished as a new digest with that digest named in the published advisory.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#coding-standard — the standard is the enforced configuration itself, listed file by file (hadolint, shellcheck, shfmt, actionlint, zizmor, yamllint, markdownlint, taplo, codespell, editorconfig), deliberately rather than as a restatement that would drift.

Enforced mechanically and twice over: lefthook git hooks run the full lint suite on every commit, and required status checks on main run the same tasks in the same order. There are no bypass flags, and personal overrides are confined to a gitignored lefthook-local.yml.

No native binaries are generated. Nothing is compiled in this repository: the image installs prebuilt PGDG packages and copies a prebuilt extension out of a digest-pinned build stage, so there are no CC, CFLAGS or LDFLAGS invocations to honour.

Nothing is compiled here, so there is no debugging-information setting to preserve.

There is no recursive build system — a single Dockerfile driven by one Task target.

Every input is pinned, so the same commit rebuilds to the same content: both FROM lines are pinned by digest and BuildKit fails closed on any mismatch rather than warning, apt package versions are exact pins under the ARG *_VERSION convention so a missing version fails the install rather than silently resolving newer, the toolchain is pinned by mise.lock in strict/locked mode, and the publish path carries no build cache of any kind, so there is no second unreviewed source of layer content. Nothing is compiled, so there is no compiler nondeterminism to control for. Note the deliberate exception: the weekly cache-free rebuild re-resolves the transitive OS layer from trixie-security on purpose — that is the remediation mechanism (https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/decisions/0001-own-the-installation.md), and it changes inputs rather than making identical inputs produce different output.

docker pull ghcr.io/carlallenn/monumental-archive-db@<digest> — the standard installation convention for this artifact type. Uninstalling is docker rmi. The README documents the reference and the tag policy.

The image honours the official postgres image's conventions unchanged: PGDATA and the /var/lib/postgresql/data volume determine where data is written, and the consumer selects the mount. The project overrides none of them.

mise install bootstraps the pinned toolchain and the git hooks; task ci then runs the whole gate. Two commands, documented at https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#development-quick-start

Every dependency is an explicit, machine-readable pin in https://github.com/CarlAllenn/monumental-archive-db/blob/main/Dockerfile — two digest-pinned FROM lines and exact apt versions in ARG *_VERSION declarations, each with a # renovate: comment above it so the pin cannot silently lose automated coverage. Toolchain dependencies are pinned in mise.toml and mise.lock.

Renovate monitors every pin continuously (policy canon in CarlAllenn/renovate-config), trivy scans the filesystem and the built image at all severities on every pull request, and the weekly cache-free rebuild refreshes the one layer that cannot be pinned by anyone.

Nothing is vendored, forked or copied in. Every reused component is an external pin that Renovate can bump in place — the two images by digest and the apt packages by exact version — so updating a vulnerable component is a one-line change with no patch to rebase.

The image tracks the current PostgreSQL major (18) on the official image, with no deprecated interfaces in use. The PostgreSQL 19 move is a tracked, deliberately gated roadmap item rather than an automatic bump: https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/roadmap.md

Integration testing by construction — the suite boots the assembled image and queries a live PostgreSQL server rather than testing anything in isolation. It runs on every push and pull request through the CI workflow, and in the publish pipeline it runs per-architecture on native amd64 and arm64 runners and then again on the published bytes pulled back from the registry by digest. Every run reports success or failure as a required status check: https://github.com/CarlAllenn/monumental-archive-db/actions

The standing policy is stronger than 50%: a change to what the image contains must come with a smoke assertion that fails without it, precisely so a later refactor cannot silently drop it. https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#tests-are-part-of-the-change

This criterion is conditioned on at least one FLOSS tool being able to measure it, and for a Dockerfile there is none — there is no application code here to instrument. What is testable is the published artifact's behaviour, which the smoke test asserts directly against a running server.

Mandated in writing in CONTRIBUTING and applied at review as one of the four ordered review checks. https://github.com/CarlAllenn/monumental-archive-db/blob/main/CONTRIBUTING.md#tests-are-part-of-the-change

Stated in CONTRIBUTING as a requirement for an acceptable contribution, not as a suggestion.

Every linter runs at its strictest configured setting, zizmor at --persona=pedantic in particular, and the gate fails on any output with no bypass available.

https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md#secure-design-principles — economy of mechanism (the deliverable is about 95 lines of Dockerfile and a smoke script, so most defect classes are absent because the code that would contain them was never written), fail-safe defaults (digest pins fail closed in BuildKit, exact apt pins fail rather than resolve newer, the server starts non-root and cannot be talked into root because gosu is deleted), complete mediation (one publish path, one signing identity, no manual publish route, no cache), and least privilege (contents: read by default with per-job scopes annotated inline, egress-policy: block on runners, no long-lived credential in existence).

No cryptographic code is authored in this repository. It assembles a container image; cryptographic functionality in the delivered artifact is upstream PostgreSQL and OpenSSL, unmodified.

No cryptographic code is authored in this repository. It assembles a container image; cryptographic functionality in the delivered artifact is upstream PostgreSQL and OpenSSL, unmodified.

No authentication credential or private key is ever baked into the image. The database superuser secret is supplied at runtime through the official image's environment convention (or its _FILE variant, reading from a mounted secret), entirely separate from configuration, logs and image layers, and can be rotated without rebuilding or recompiling anything. On the publishing side the same property holds structurally: there is no long-lived registry or signing secret in existence to store or rotate, because GHCR authentication uses the workflow run's own short-lived token and cosign signs keylessly against an ephemeral Sigstore certificate. https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md

No cryptographic code is authored in this repository, and the software produced here initiates no network communication of its own. Network cryptography in the running database is PostgreSQL's TLS, configured by the consumer.

No TLS implementation is authored or configured here; TLS termination is explicitly the consumer's deployment decision per https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md

No cryptographic code is authored in this repository. It assembles a container image; cryptographic functionality in the delivered artifact is upstream PostgreSQL and OpenSSL, unmodified. The software produced here implements no TLS client.

No cryptographic code is authored in this repository. It assembles a container image; cryptographic functionality in the delivered artifact is upstream PostgreSQL and OpenSSL, unmodified. The software produced here implements no TLS client and sends no HTTP headers.

Every published manifest is cosign-signed keylessly, with this repository's publish workflow on main as the certificate identity — the ref is anchored in the pattern (@refs/heads/main$), so a signature minted from any other ref does not verify. The pipeline then runs cosign verify against that exact identity immediately after signing, because a signing step that exits 0 is not the same as a signature that verifies. The verification process is documented for users at https://github.com/CarlAllenn/monumental-archive-db/blob/main/SECURITY.md#verifying-what-you-pulled and repeated in the README. This criterion's requirement that the private key not live on the distribution site is satisfied absolutely rather than by policy: keyless signing means there is no private key at rest anywhere — the Fulcio certificate is ephemeral and bound to the workflow's OIDC identity. Images additionally carry SPDX SBOM and provenance (mode=max) attestations.

The delivered artifact validates all client input: PostgreSQL's parser and type system reject malformed input by construction, and the one validation surface this project deliberately adds — edtf_postgres — is a strict, fail-closed EDTF validator, chosen precisely so the database and the archive's web layer cannot diverge in what they accept. Stated plainly for provenance: none of that validation code is authored in this repository, and this repository's own executable content (two shell scripts) takes no untrusted input at all.

The server runs as USER postgres with no root phase and no setuid path to one, because gosu is deleted; /docker-entrypoint-initdb.d is emptied; workflows default to contents: read with per-job scopes annotated inline; runners enforce egress-policy: block; every checkout sets persist-credentials: false. https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md#secure-design-principles

https://github.com/CarlAllenn/monumental-archive-db/blob/main/docs/assurance-case.md — threat model in order of exposure, the four supply-chain substitution points, explicit out-of-scope boundaries, the five trust boundaries, secure design principles tied to mechanisms, a table of common implementation weaknesses with countermeasures and evidence, and a closing section naming the residual risks honestly rather than claiming there are none.

trivy at all severities with --ignore-unfixed over both the filesystem and the built image on every pull request, plus CodeQL's actions analysis for workflow-level vulnerability patterns. The scan tasks are deliberately never checksum-fingerprinted, because vulnerability databases change without commits and a cached skip would be a false pass.

No memory-unsafe code is authored here; the only executable content written in this repository is two shell scripts.