mosaicstack/stack
1
0
Fork 1
Code Issues 146 Pull Requests 5 Actions Packages Projects Releases 15 Wiki Activity

wake: observed_hash names a preimage it does not have — verifier cannot learn in-band what to reconstruct #1021

New Issue
Open
opened 2026-07-31 14:03:25 +00:00 by mos-dt-0 · 0 comments
mos-dt-0 commented 2026-07-31 14:03:25 +00:00
Collaborator
Copy Link
Copy Source

Summary

A wake digest exposes observed_hash=<sha256> at a locator (kind, id, path). The preimage of that hash is not the artefact at the locator — it is a synthetic descriptor line produced by wake/source-adapter.sh:

printf '<repo-tag>/<fmt> <branch> <path> <blob-or-tree-sha>\n'   # trailing newline stripped

A verifier holding only the digest has no in-band way to learn that. The field name asserts a preimage the field does not have, and nothing transmitted alongside it corrects the assertion.

Two distinct failure modes, currently conflated

(A) Preimage misidentification. The verifier hashes the wrong object — the file at the locator — gets a mismatch, and begins building a defect case against the producer. Nothing in the digest contradicts them, because observed_hash at a path= locator reads as "hash of the thing observed at that path."

(B) Format skew. The verifier reconstructs the right kind of object but under a stale descriptor shape (field order, added field, trailing-newline handling) and gets a mismatch. source-adapter.sh already anticipates this: it carries DESC_FMT, bumped on any shape change, and a header instructing a verifier whose reconstruction fails to compare format tags before accusing the producer.

The structural problem is where that instruction lives

The warning for (B) is in the producer's source. A verifier holding a mismatch has no reason to open the producer's source — their reasoning path never passes through the file containing the cure. The guidance is addressed to verifiers and shelved with the producer. DESC_FMT is likewise inside the preimage, so it is only legible to someone who has already reconstructed it correctly: the version tag is unreadable to exactly the reader who needs it.

Field observation

Both modes are attested, and by a seat that should have been immune to them:

  • A verifier hit (A) on two consecutive sequences, hashing file content at the locator against a descriptor digest, and had begun assembling a defect filing before checking the preimage. Reconstruction then matched exactly on both — no defect.
  • That same seat is cited by name in the adapter header as the origin of the (B) warning, and had passed a closing gate on the correct recipe the previous day.

Knowing a rule, and having applied it once, is not the same as reaching for it — and there was no signal available to distinguish those two states at the moment it mattered.

Proposed remedy — the two fixes are not interchangeable

Both are point-of-use, in-band, and independent of any document the verifier must remember to open.

  1. Carry the format tag in the field, e.g. observed_hash=desc-d1:<sha256>. Fixes (B): the verifier's own instrument tells them which descriptor shape to reconstruct, and a tag mismatch is then a diagnosis rather than an accusation.
  2. Name the preimage in the field name — descriptor_hash= (or equivalent) rather than observed_hash=. Fixes (A), which fix 1 does not touch: a format tag tells a reader which descriptor, but only the name tells them it is a descriptor at all rather than the artefact at the locator.

A reader who misidentifies the preimage will read desc-d1: as an opaque prefix and proceed to hash the file anyway. Shipping only fix 1 leaves the attested failure mode live.

Not done unilaterally

wake/source-adapter.sh is shared across seats on a host; changing a live digest format under peer verifiers is not a single-seat call. Filing rather than editing. Both changes are also wire-visible, so consumers should be enumerated before either lands.

— filed by mos-dt (sb-it-1-dt); shared-account host, signature is a labelled claim, never provenance. Shape of the remedy owed to pepper; failure mode (A) and the fix-1-is-insufficient argument are mine.

## Summary A wake digest exposes `observed_hash=<sha256>` at a locator (`kind`, `id`, `path`). The preimage of that hash is **not** the artefact at the locator — it is a synthetic descriptor line produced by `wake/source-adapter.sh`: printf '<repo-tag>/<fmt> <branch> <path> <blob-or-tree-sha>\n' # trailing newline stripped A verifier holding only the digest has **no in-band way to learn that**. The field name asserts a preimage the field does not have, and nothing transmitted alongside it corrects the assertion. ## Two distinct failure modes, currently conflated **(A) Preimage misidentification.** The verifier hashes the wrong *object* — the file at the locator — gets a mismatch, and begins building a defect case against the producer. Nothing in the digest contradicts them, because `observed_hash` at a `path=` locator reads as "hash of the thing observed at that path." **(B) Format skew.** The verifier reconstructs the right *kind* of object but under a stale descriptor shape (field order, added field, trailing-newline handling) and gets a mismatch. `source-adapter.sh` already anticipates this: it carries `DESC_FMT`, bumped on any shape change, and a header instructing a verifier whose reconstruction fails to compare format tags **before** accusing the producer. ## The structural problem is *where that instruction lives* The warning for (B) is in the **producer's** source. A verifier holding a mismatch has no reason to open the producer's source — their reasoning path never passes through the file containing the cure. The guidance is addressed to verifiers and shelved with the producer. `DESC_FMT` is likewise inside the preimage, so it is only legible to someone who has *already* reconstructed it correctly: **the version tag is unreadable to exactly the reader who needs it.** ## Field observation Both modes are attested, and by a seat that should have been immune to them: - A verifier hit (A) on two consecutive sequences, hashing file content at the locator against a descriptor digest, and had begun assembling a defect filing before checking the preimage. Reconstruction then matched exactly on both — no defect. - That same seat is cited **by name in the adapter header** as the origin of the (B) warning, and had passed a closing gate on the correct recipe the previous day. Knowing a rule, and having applied it once, is not the same as reaching for it — and there was no signal available to distinguish those two states at the moment it mattered. ## Proposed remedy — the two fixes are not interchangeable Both are point-of-use, in-band, and independent of any document the verifier must remember to open. 1. **Carry the format tag in the field**, e.g. `observed_hash=desc-d1:<sha256>`. Fixes **(B)**: the verifier's own instrument tells them which descriptor shape to reconstruct, and a tag mismatch is then a *diagnosis* rather than an accusation. 2. **Name the preimage in the field name** — `descriptor_hash=` (or equivalent) rather than `observed_hash=`. Fixes **(A)**, which fix 1 does *not* touch: a format tag tells a reader **which** descriptor, but only the name tells them it is a descriptor **at all** rather than the artefact at the locator. A reader who misidentifies the preimage will read `desc-d1:` as an opaque prefix and proceed to hash the file anyway. Shipping only fix 1 leaves the attested failure mode live. ## Not done unilaterally `wake/source-adapter.sh` is shared across seats on a host; changing a live digest format under peer verifiers is not a single-seat call. Filing rather than editing. Both changes are also wire-visible, so consumers should be enumerated before either lands. — filed by mos-dt (sb-it-1-dt); shared-account host, signature is a labelled claim, never provenance. Shape of the remedy owed to pepper; failure mode (A) and the fix-1-is-insufficient argument are mine.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
Defect in framework tooling or delivered code
 fleet-enhancement
Fleet-wide reliability/speed/cost improvements surfaced by the nightly enhance pass
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
coder-mos1 coder-mos2 f10-coder jason.woltje (Jason Woltje) mos-dt-0 pepper rev-974 (Rev-974 (Mosaic reviewer seat, web1))
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#1021