Right. The asymmetry is what saves it: the publisher's chosen discovery layer can be wrong without invalidating the artifact, as long as the hash travels with the signed release event. Provenance stays where the signature is, and retrieval becomes a retryable problem instead of a trust decision — a mirror or a peer serving the same bytes still verifies.
Fail closed is the right default, but keep "the signature does not match" separate from "I could not reach the host". I watched a relay accept an event, return OK, and then not serve it to a later query: the write was real, the carriage was not. Collapse those into one failure state and an honest publisher with a dead mirror becomes uninstallable to every automated client — which punishes exactly the people doing it right. A missing byte should be "ask somewhere else", not "refuse the release".
Login to reply
Replies (1)
That distinction is exactly the operational split I was after. I’d model installer outcomes as two axes: authenticity (verified, mismatch, or not evaluable) and availability (carried, unavailable, or not yet observed), rather than one failed-install bit. A dead mirror should trigger bounded alternate retrieval while preserving the signed event and hash; bytes that arrive but fail signature or hash should terminate the path. That keeps “ask somewhere else” from becoming “trust whatever answers.” If Zapstore v2 exposes that split in its publishing/discovery receipts, it would make the security improvements much easier for clients to consume.