Colophon · running v1.2.1
How this site is built
The stack, the release flow, and enough to check my work: the signing key, a verify command, and the SBOM and vulnerability report for every release.
Stack
Astro 7 with static output, Svelte 5 for the few interactive islands, Tailwind 4 for styling. The build is copied into an nginx 1.31 Alpine container that runs as an unprivileged user behind a Cilium gateway on lillecloud, my Talos cluster on Hetzner (more on the now page). ArgoCD deploys whatever image tag the infrastructure repository names. Renovate opens the dependency and base-image pull requests. There is no hosted CI.
Release flow
Every release is cut from my own machine with a Taskfile. The cosign key and its password live in 1Password and are read into the environment for the one command that needs them. They are never written to disk and there is no CI runner to leak them from.
- Preflight: refuse to release from any branch but main, or to republish a version that already exists in the registry.
- Build the image with Podman and run the health and smoke checks against it (headers, compression, caching, vhost allowlist).
- Push to ghcr.io.
- Resolve the digest from the registry and sign that digest with cosign. The tag is never what gets signed.
- Verify the signature offline with the public key, exactly as the cluster policy does.
- Trivy writes a CycloneDX SBOM and a vulnerability report for the image.
- Commit the version, the digest, the SBOM and the report to the repository.
Deployment is a separate step: Renovate in the infrastructure repository notices the new tag and opens the pull request that bumps it.
Why a key, not keyless
The signature is a plain key pair rather than a keyless identity tied to a GitHub login. If I leave GitHub, or GitHub leaves me, the key still verifies every image I ever signed. The price is transparency: the signatures are not uploaded to Rekor, so a verifier has to say so explicitly with the flag in the command below.
Verify it yourself
The current public key is served at /cosign.pub and committed in the repository as cosign.pub. Releases from July 2026 onward are signed with it; the three releases before that which carry a signature were signed with the 2025 key. The table below says which is which.
-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEcinYmcKT7QBe48DesANXk+P/uGYY
OIGoPhTYeYOs+4N1RWXQOOKfoTWk6zfK/R2IzGvnJeGnNNTbQlMwFYgp4A==
-----END PUBLIC KEY-----This verifies the image behind the newest signed release, v1.2.0:
curl -sO https://lillevang.dev/cosign.pub
cosign verify --key cosign.pub --insecure-ignore-tlog=true \
ghcr.io/lillevang/website@sha256:43ffa47f2679fe51e016557e6ec22e46b20c39ea675286b50d729b1c982552b6The package on ghcr.io is public, so this needs no login. The same command, with the key read from 1Password, is what the release pipeline runs before the Trivy step.
Releases
| Version | Date | Digest | Signed with | Findings | Artifacts |
|---|---|---|---|---|---|
| 1.2.0 | 2026-10-13 | sha256:43ffa47f2679fe51… | current key | none | SBOM·report |
| 1.1.22 | 2026-10-13 | sha256:d37cb1d574c33e3f… | current key | none | SBOM·report |
| 1.1.21 | 2026-09-14 | sha256:d000c0ba1e1d13dc… | current key | none | SBOM·report |
| 1.1.20 | 2026-09-13 | sha256:a433d5edd60c0cb8… | current key | 4 high, 14 medium, 32 low | SBOM·report |
| 1.1.19 | 2026-07-17 | sha256:39b5d2f3f128df8e… | current key | 2 high, 8 medium, 20 low | SBOM·report |
| 1.1.18 | 2026-07-05 | sha256:d64f30c5a63cb238… | unsigned | 2 high, 8 medium, 20 low | SBOM·report |
| 1.1.17 | 2026-07-04 | sha256:e348fe51231d3b22… | unsigned | 2 high, 8 medium, 20 low | SBOM·report |
| 1.1.16 | 2026-07-03 | sha256:e1aafff347762ecd… | 2025 key | 2 high, 8 medium, 20 low | SBOM·report |
| 1.1.14 | 2026-06-06 | sha256:35e72588f5b85339… | unsigned | none | SBOM·report |
| 1.1.13 | 2026-05-04 | sha256:f62a39d37797fb26… | unsigned | none | SBOM·report |
| 1.1.12 | 2026-05-04 | sha256:9a7d666b80db7d4c… | unsigned | none | SBOM·report |
| 1.1.11 | 2026-05-04 | sha256:b7fc62ea0800b804… | unsigned | none | SBOM·report |
| 1.1.10 | 2026-05-02 | sha256:d11edfb8fdc4b731… | unsigned | none | SBOM·report |
| 1.1.9 | 2026-05-01 | sha256:81ffa2ddca3a1791… | unsigned | none | SBOM·report |
| 1.1.8 | 2026-05-01 | sha256:1d3b2e90fa43c981… | unsigned | none | SBOM·report |
| 1.1.7 | 2026-05-01 | sha256:14b6c4de345e0d98… | unsigned | none | SBOM·report |
| 1.1.6 | 2026-05-01 | sha256:7a7889ee0cae396a… | unsigned | none | SBOM·report |
| 1.1.4 | 2026-04-13 | sha256:d11adb1dc6253fe6… | unsigned | none | SBOM·report |
| 1.1.3 | 2026-04-12 | sha256:c3c8e4620e97aa34… | unsigned | 2 critical, 6 high, 19 medium, 11 low, 4 unknown | SBOM·report |
| 1.1.2 | 2025-12-01 | sha256:61a798fc8ed75358… | 2025 key | n/a | SBOM·no report |
| 1.1.1 | 2025-08-03 | sha256:4da86362d8a75497… | 2025 key | n/a | SBOM·no report |
A row is written when a release is signed, so the newest row can be one behind the version in the footer.
Honest limits
- Kyverno on the cluster checks the signature of every ghcr.io/lillevang image, but in audit mode. An unsigned image would be reported, not blocked.
- The signatures are not in a transparency log. Trust rests on the key alone.
- Not every release in the table carries a signature. The ones marked unsigned were pushed before signing was part of every release, or while the key moved into 1Password; they are still in the registry as they were.