stack-single 1.4.2

stack-single 1.4.2

A patch that moves every Go image this launcher pins to a release built on Go 1.27.3, which fixes GO-2026-6809 in crypto/x509. Three of the moves also bring the service releases in between (wardryx 2.4.0, heraldyx 0.8.1, keyryx 0.1.2), so read Upgrade first.

Upgrade first

1. Run ./install.sh again from this release. A box with its own operator files names them as before (CLIENT_KEYS_FILE=... IDENTITY_MAP_FILE=...). The installer verifies each new image's signature, pulls it by digest and recreates the services it changes; on the measured box below that was the eight moved services plus the gateways, the console and caddy, while the database, the control plane, the record seal and costcrew kept running.
2. wardryx 2.4.x with agent tokens on. With agent tokens on, the installer sets WARDRYX_AGENT_TOKEN_ISSUER, and wardryx 2.4 accepts each agent DPoP proof for one decision only: a proof presented twice is refused with 403 agent_token_proof_invalid. TokenFuse 1.19.0, pinned here, sends each request's own proof once per decision, and refuses a replayed proof at its own door before wardryx is asked (measured on a live box, below). This launcher does not set WARDRYX_APPROVER_JWKS, so approvals decided with a key work as before.
3. heraldyx 0.8.x reads a stream file entry only while it is a regular file. The entry this launcher writes, /var/lib/keyryx-alerts/keyryx.ndjson, is the file the Keyryx witness writes on its own keyryxalerts volume, mounted read only into heraldyx. A box whose operator replaced it with a link or a directory must point the entry at the real file.
4. keyryx 0.1.2 and later write attestations 0640 in 0750 directories. Attestations written by keyryx 0.1.1 keep 0600. This launcher does not wire a reader of attestations, so nothing here needs them; a box that wires one can run the one-time chmod in keyryx's docs/releases/v0.1.2.md.

What changed

Image	1.4.1	1.4.2
heraldyx	v0.8.0	v0.8.2
idryx	v1.3.0	v1.3.1
keyryx	v0.1.1	v0.1.3
scopyx	v1.1.0	v1.1.1
scopyx (chromium)	v1.1.0-chromium	v1.1.1-chromium
typryx	v0.5.0	v0.5.1
vouchryx	v0.6.0	v0.6.1
wardryx	v2.3.0	v2.4.1

• Each image is pinned by tag and digest in compose.yaml, components.json and install.sh (#153). Every one was built on golang:1.27.3 or golang:1.27.3-alpine, read from its build provenance. The teeth cases, the image-verify fixtures, scripts/typed-data-mode.sh and the README lines that name these pins follow them.
• The README's own-files example names the broker and agents entries that agent tokens need (#152).

Measured

• forge, 2026-10-26, upgrading from 1.4.1 to the tree of this release (a7e9a44), with agent tokens on and its own operator files: installer exit 0, 59 checks ok, none failed; every service came up on its new image with no restart; install.sh status 49 ok. A second run: 59 ok, no container recreated, .env unchanged.
• Agent tokens on the same box with wardryx 2.4.1, using docs/evidence/agent-token-audience/measure.sh (agent agent://home.taipanbox.dev/agents/operator, BUDGET_USD=0.000001): 10 of 10 expectations held. Each run produced two wardryx decisions, one for the gateway and one for a broker tools/call, each policy_allow with attestation dpop-key, and no agent_token_proof_invalid. The same measurement on 1.4.1, before the upgrade, gave the same result.
• One proof sent twice to the gateway, five seconds apart (longer than the gateway's three-second decision cache): the first was admitted (a wardryx allow, then 402 at the budget step), the second was refused at the gateway's own door (401 agent_token_refused, logged as Replayed), so wardryx was not asked.
• CI on #153: eight checks green, six of them full installs with these pins.

Not measured

• A box with agent tokens off was not upgraded live; the CI install legs cover that path.
• The one-time chmod of older Keyryx attestations was not run: nothing on this launcher reads them.
• TokenFuse stays at 1.19.0 here; stack-k8s pins 1.20.0, which this release does not take.