Pipeline 11 recorded nothing: the clone plugin ran `git fetch --depth=1
--filter=tree:0` with depth: 100 set, so `git log <serving>..<this>`
could not name the commit it replaced. The repo is anonymously readable
on Gitea, so the release step deepens by 100 itself before it renders
the notes. The clone setting goes back to what it was.
Woodpecker's k8s backend runs every step through /bin/sh. crane:debug
carries only /busybox/sh, so the fetch-courier step died at container
init (pipeline 10). The release step now fetches the manifest by digest
from zot, tries each blob as a gzip tar for usr/local/bin/courier and
stops at the one that has it — busybox wget, tar and gzip, which
alpine/git has. Proven in that image before this push.
Two steps after deploy: crane exports the courier CLI out of courier's
own (distroless) image, pinned by tag and digest, and alpine/git runs
`courier deployed hush prod $CI_COMMIT_SHA` as the `releases` agent —
one immutable version of releases/hush.prod carrying git log
<serving>..<this>, and one message on `deploys` keyed on that version.
The deploy step writes the image that was serving to .prev-sha before
`set image`, so the notes are what replaced what. Clone depth goes
1 → 100 so that log can be rendered. The credential is the Woodpecker
secret courier_releases_token, scoped to the alpine/git image and push
events. Same call every other substrate makes — orchard9-k3sf
scripts/lib/release.sh is the reference.
Paste a secret, get a link, send it. The first person to open it and press
Reveal sees the secret; the link dies at that moment. The recipient needs a
browser and nothing else — no account, no client, no installed tooling.
The server cannot read what it stores. AES-256-GCM happens in the browser and
the key lives in the URL fragment, which browsers never transmit, so hushd
holds ciphertext and no key material. That is a property of where the key sits
rather than a promise about our conduct, which is why there is deliberately no
endpoint accepting a plaintext secret and no server-side-encryption fallback:
two guarantees behind one URL would be worse than one honest guarantee.
Three decisions carry the design:
* GET /s/{id} touches NO storage, not even to check existence. Slack, Teams,
WhatsApp, iMessage and Outlook Safe Links all fetch a URL before a human
sees it, so destroying on GET would destroy most secrets in transit and the
recipient's "already used" would be indistinguishable from interception.
Only POST /reveal consumes. Bot user-agent detection is an arms race;
removing the side effect from GET is not. Pinned by
TestGettingTheRevealPageNeverConsumesTheSecret.
* Destruction is one Redis GETDEL, which is atomic. GET-then-DEL has a window
where two simultaneous readers both win, and for a one-time secret that
window is the product. The store contract demands atomicity and the same
concurrency test runs against both implementations.
* Missing, already-revealed, expired and evicted are ONE indistinguishable
410. Separating them would confirm to a prober that a given link was real.
The secret id IS the capability, so secret.ID is a struct whose every
accidental path — %v, %s, String(), slog, json.Marshal — emits a redacted
handle or refuses, and the raw value needs an explicit Value(). The first
version tried to prevent leaks by implementing no String() at all; its own test
caught that Go's fmt prints unexported fields anyway, so forbidding the method
had removed the control rather than the leak.
Operationally: structured JSON on stdout in the fleet's wire format, which
Vector already collects with no annotation; six hush_* metrics on the chassis
registry with no id, IP or path in any label; five alert rules wired into
vmalert. The public Ingress enumerates /, /s/ and /api/ so /metrics, /healthz
and /readyz share the port but are unreachable from the internet — no
basic-auth middleware to maintain and get wrong.
Dependencies are vendored because go-chassis is private: the Woodpecker test
step and the in-cluster Kaniko build both run -mod=vendor with GOPROXY=off and
hold no git credential.
cmd/hush-mcp is a stdio MCP server doing the same client-side crypto locally,
so using hush from an agent preserves the same guarantee as using it from a
browser.
