Phase 11. Registry mirror protocol
| Field | Value |
|---|---|
| MEP | MEP-57 §Phases · Phase 11 |
| Status | NOT STARTED |
| Started | — |
| Landed | — |
| Tracking issue | — |
| Tracking PR | — |
Gate
TestPhase11Mirror: a mock mirror serves the same content as the upstream and resolves identically; a mock mirror that serves modified content fails Sigstore verification; failover from default to alternate works on upstream 503.
Pass criteria:
- Mirror parity. A mirror populated by
mochi pkg mirror syncfrom a known upstream root resolves every fixture identically to direct upstream resolution; the produced lockfile is byte-identical. - Tamper resistance. A mirror that returns a tarball whose BLAKE3 does not match the index entry's
b3raisesM057_BLOB_E001and the client moves to the next alternate. - Sigstore preservation. A tarball with a hash that matches but whose Sigstore bundle does not verify against the trust root raises
M057_SIG_E004and is also rejected (proves a mirror cannot substitute a "validly hashed" tarball that lacks signature, once Phase 13 is enabled). - Failover. With
upstream = "https://index.mochi.dev"and[[registry.alternate]] url = "https://mirror.corp/internal", a primary 503 routes to the alternate; on alternate 200 the resolution succeeds and the lockfile records the source mirror in[provenance]. - Divergence detection.
mochi pkg audit mirror corpcompares a sample of upstream index entries against the mirror and reports any divergence withM057_INDEX_E006. - Sync efficiency. A second
mochi pkg mirror syncagainst an already-populated dest skips entries whose ETag is unchanged; the test asserts only changed entries trigger blob copies.
Goal-alignment audit
Mirrors are the operational answer to "what if the central registry goes down". Without them, an outage at index.mochi.dev blocks every Mochi build globally. The user-facing goal moved: "My corporate proxy hosts a Mochi mirror; my builds resolve against it transparently and Sigstore still verifies".
The threat model that justifies Phase 11 explicitly: a corporate mirror is not a trust boundary. The mirror operator may be compromised; the upstream signer is the only trusted party. Therefore every blob fetched via a mirror must verify identically to one fetched from upstream (same BLAKE3, same SHA-256, same Sigstore bundle). The mirror is an availability mechanism, not an authorisation mechanism.
This contrasts with corporate package proxies in the Java/Python world (Artifactory, Sonatype Nexus), where the proxy can re-sign or rewrite. Mochi's mirrors are content-addressed pass-throughs; rewriting would invalidate the signature chain.
Sub-phases
| # | Scope | Status | Commit |
|---|---|---|---|
| 11.0 | Mirror discovery: [[registry.alternate]] parsed, fallback chain | NOT STARTED | — |
| 11.1 | Failover semantics on upstream error | NOT STARTED | — |
| 11.2 | Sigstore + dual-hash verification preserves against mirror substitution | NOT STARTED | — |
| 11.3 | mochi pkg mirror sync --upstream=<url> --dest=<dir> | NOT STARTED | — |
| 11.4 | mochi pkg mirror serve --root=<dir> | NOT STARTED | — |
| 11.5 | mochi pkg audit mirror <name> cross-check | NOT STARTED | — |
| 11.6 | Mirror source recorded in lockfile [provenance] | NOT STARTED |