A release whose only content is the compiler. Nothing cairn does has changed.
馃敀 Security
The image is rebuilt with go1.26.6. The weekly Trivy scan failed on 17
August with eight HIGH findings, and they are not eight problems: all eight are
the Go standard library at v1.26.5, which is what the pinned base image
carried, and all eight are fixed in 1.26.6.
| CVE | package |
|---|---|
| CVE-2026-56858 | html/template, cross-site scripting via pathological input |
| CVE-2026-56853 | net/http, denial of service on unencrypted HTTP/2 |
| CVE-2026-56862 | crypto/tls, denial of service via indefinite KeyUpdate |
| CVE-2026-56860 | net/url, quadratic complexity in path handling |
| CVE-2026-56859 | encoding/xml, decoding recursion depth |
| CVE-2026-33818 | encoding/asn1, recursion in Unmarshal |
| CVE-2026-46600 | x/net/dns/dnsmessage, invalid record parsing |
| CVE-2026-39821 | x/net/idna, punycode label processing |
The first is the one worth reading twice, because every page cairn serves is
rendered through html/template and that package is the escaping between a
value and the browser.
What reaches it, precisely. Your own YAML, and what a monitor you pointed
cairn at reports: the endpoint key a status page returns is what builds the
pill's deep link. Not anything a visitor types, since the search runs in the
browser and never asks the server. So the practical exposure is narrow. Narrow
is not none, and an escaping layer is the wrong place to reason about margins.
The rest are denial of service in code paths cairn either never runs or never
exposes. They are listed because they were in the binary, not because a case
has been made for any of them.
Nothing else moved. The two images were served the same configs on the same
port and every response compared, both stamped with the same version so the
footer could not account for a difference: 155 responses across three configs,
zero bytes apart. The six README screenshots were regenerated and came back
byte identical too.
馃Ч Internal
Why the pin went stale. The Dockerfile said Dependabot watched it. It does
not. Its log says the same thing every week:
Checking if library/golang 1.26-alpine needs updating
Latest version is 1.26-alpineIt compares tags. 1.26-alpine is already the newest tag, so a digest sliding
from one patch release to the next underneath it is invisible to it, and it has
never opened a pull request for that file.
No new watcher was added. Raising the pin on every golang rebuild would mean a
weekly red build for nothing. Trivy is the right watcher precisely because it
is late: it fires when the Go left behind starts carrying a published CVE,
which is the moment it matters. The comment in the Dockerfile now says that
instead of the thing that was not true.
govulncheck stayed green throughout, and that is not a contradiction. It
analyses the source with the runner's own toolchain, which was already patched.
It answers whether the source is vulnerable; Trivy answers whether the artifact
is. Only the second question is about what you pull.
The buildkit pin moved with buildx-stable-1, which is the other half of
what the same run reported.
馃摝 Image
docker pull morgankryze/cairn:1.19.3 # or: ghcr.io/morgankryze/cairn:1.19.3This release also moves 1.19, 1, stable and latest, on both registries.
Docker Hub gets the digest ghcr signed, copied rather than rebuilt, so the two
are the same object and cosign verify works on either. The chart is at
oci://ghcr.io/morgankryze/charts/cairn version 1.19.3, signed the same way:
cosign verify morgankryze/cairn:1.19.3 \
--certificate-identity-regexp '^https://github.com/MorganKryze/cairn/' \
--certificate-oidc-issuer https://token.actions.githubusercontent.comUpgrading needs nothing: no config shape changed, and -check on 1.19.3
accepts everything 1.19.2 accepted.