Release integrity: content-addressed assets, the tiny mutable bootstrap, signed manifests, third-party monitoring

[lannbot]

Positioned as supply-chain hygiene and publisher/host separation, not as the trust-model foundation (the origin is fully trusted; static-only bounds its attack surface, not its blast radius). Confirm or contest that positioning here. See NOTES.md — Release integrity.

The bootloader shape:

• Content-addressed immutable assets (hash-named, Cache-Control: immutable); a single tiny mutable root (entry HTML + SW registration) that changes only on release.
• Optionally the root verifies a signed release manifest before activating cached assets. The circularity (verifier served by the same origin) is acknowledged and acceptable under the trust statement; the discipline still shrinks the practical attack surface to a ~2KB diffable bootstrap.

Detection layers that stack on top, in rough cost order: CT-log monitoring of origin certs; third-party monitors comparing origins to published release hashes (meaningful only because releases are byte-identical — and weakened by per-user subdomains: clean bytes to canary.host, different bytes to alice.host); peers gossiping release hashes over iroh (targeted delivery detectable via contacts); an optional verification extension (Code Verify precedent). Isolated Web Apps as a possible future tier, not the baseline.

Open sub-questions:

• Reproducible builds: how close can the toolchain get, and what does the manifest sign if not bit-reproducible?
• Signer/key management for releases; where the manifest format lives.
• Whether hash-gossip over iroh is worth its complexity at v1 or is a later layer.

[lannbot]

Design refinement: the constant-root bootloader (2026-08-17)

From design discussion, prompted by the question: could updatable signed framework code be bootstrapped from a single digest-pinned static script? Answer: yes — a strict refinement of the bootloader shape in the issue body. Recorded in NOTES.md §Release integrity (PR #23). Leaning, not ruling.

Mechanism: service worker as bootloader

• Constant root set: a trivial entry HTML (registers the SW, nothing else) plus the bootstrap SW script. Both immutable-forever in the honest case; monitors pin their digests as constants. Two files is the floor — a SW must be a same-origin URL-addressed script registered from a document, so the HTML shell can be made inline-auditable but not eliminated.
• The SW embeds the publisher root keys, fetches a small mutable signed release manifest, verifies via WebCrypto (Ed25519 + SHA-256 — no crypto code frozen into the bootstrap), then fills the Cache API with content-addressed assets, verifying each hash at cache-fill time.
• The SW serves everything — including navigations, so post-install even the entry HTML comes from verified cache — at real URLs with real headers: correct application/wasm MIME for streaming compilation, strict CSP (script-src 'self', no eval/blob loading). Verification happens at cache-fill; execution semantics stay boring.
• A release = new content-addressed assets + a new signed manifest. The root never changes; releases are invisible to root-level monitoring, by design.

What it buys over the founding sketch

The mutable-root sketch makes monitors diff a moving target against a release feed. This collapses the canary predicate to a constant: "origin serves digest X at these two URLs, forever." Any deviation is prima facie compromise or a rare, loud, signed bootstrap upgrade. Publisher/host separation gets teeth: in the honest-root case, what code runs is gated by the publisher key, not origin control — a host/CDN deploys releases but cannot author them. This also simplifies the multi-tenant wildcard story and self-hosting: hosts sync bytes; the trust chain never depends on their deploy discipline.

What it cannot buy

• The platform has no pinning primitive. register() takes no integrity metadata (there is no SRI for SW scripts — known platform gap), and the SW update check fetches the script directly, bypassing the SW's own fetch handler by spec. A compromised origin ships a replacement bootstrap and wins within ~24h / next navigation. First visit and post-eviction are TOFU from the origin.
• So the trust-model positioning in the issue body stands unchanged: detection-shaped, not prevention-shaped. Prevention remains the extension tier or IWA packaging — though both get cheaper: a Code-Verify-style extension now pins two constant hashes instead of tracking a release feed.
• The per-user-subdomain canary caveat (clean bytes to canary.host, dirty to alice.host) applies unchanged. Constant digests sharpen the peer-gossip cross-check but do not fix targeted serving.

The hard sub-problems (crib TUF's role structure rather than re-derive)

1. Rollback. Signatures admit replay of an old signed manifest. The SW persists a monotonic release version and hard-fails on regression.
2. Freshness vs local-first. Hard manifest expiry would brick offline use, which local-first exists to serve — freshness is advisory (staleness warning), and multi-device gossip of (release version, root digest) catches targeted freezes: "your origin served v37, mine saw v42."
3. Root rotation inside a never-changing file. Embed k-of-n root keys and accept TUF-style signed root-rotation chains from the baked-in set. Otherwise key loss is pin suicide (the HPKP lesson) and key compromise forces the alarm event.
4. Eviction = re-TOFU. Storage eviction silently wipes the rollback counter and the verified cache; the failure mode is a silent downgrade to first-visit trust. Detect and surface it.
5. Frozen bugs. Every bootstrap bug lives until a root change — the exact event monitors alarm on. Keep it tiny, dependency-free, format-versioned from day one; define the loud upgrade path (new root signed by the root chain, so monitors verify continuity, not just change).

Effect on the open sub-questions in the issue body

• Signer/key management; where the manifest format lives: now has a concrete frame — TUF's root/targets/snapshot/timestamp decomposition is the checklist (rollback and freshness are the snapshot/timestamp roles; rotation is root versioning). k-of-n embedded roots plus chained rotation is the starting posture.
• Hash-gossip over iroh at v1: the payload sharpens to (release version, root digest) and the check gets cheap because the reference is constant. Cost/benefit still open, but the freeze/rollback detection it buys is now named.
• Reproducible builds: untouched by this refinement — still open (what the manifest signs if not bit-reproducible).

New open sub-questions this adds: WebCrypto Ed25519 availability floor across target browsers (feature-detect; ECDSA P-256 is the universal fallback if the tail matters); updateViaCache/update-check cadence details as part of the home-origin contract (#2); whether the bootstrap SW and the origin conformance checker (#2) share test machinery.

Prior art consulted: TUF (role structure), Meta's Code Verify (extension precedent), Isolated Web Apps (platform prevention tier), HPKP deprecation (pin-suicide lesson), and the SW-integrity platform gap (w3c/ServiceWorker discussions on SRI for SW scripts).