Gap
A relying party can verify what code an app runs right now (RFC 0020 / RFC 0015), but cannot get a trustworthy answer to 'what are ALL the code versions this URL has ever served?' Today the per-app history is weak:
- Per-boot only. Attested deploys extend the RTMR via
EmitEvent (proxy/audit.py _extend_rtmr), but the RTMR resets on CVM reboot and recover_all() (proxy/runtimes.py) never re-anchors the historical log. So the live quote vouches only for this boot's deploys; earlier versions live solely in the per-project audit jsonl — a mutable file on the daemon volume.
- Attested-mode only.
deploy.py: if mode == 'attested'. Dev-mode windows, and any un-promote → re-promote cycle (the RFC 0026 debug path), are invisible.
- Soft-fail.
_extend_rtmr only log.warnings; the deploy succeeds even if it wasn't anchored — completeness isn't enforced.
- No manifest history.
project.json is overwritten with only the current pin; the jsonl is the history.
Contrast (why this is a real asymmetry)
The daemon's own code versions ARE anchored the strong way: ComposeHashAdded/ComposeHashRemoved on the base-KMS AppAuth contract — permanent on Base, reset-proof, no trust in the operator. Tenant apps deserve the same 'provable version set ever' property.
Ask
Give each app a durable, tamper-evident version ledger:
- Emit each attested version change durably — on-chain (like the daemon's compose hashes) and/or a persisted, re-anchored, attested hash-chain (replay the log into RTMR on boot so the current quote covers all history).
- Unconditional + fail-closed: record every version (all modes), and a deploy that can't be anchored should fail or be flagged, not silently succeed.
- Cover the promote / un-promote transitions so there are no silent gaps.
Relation
Completes RFC 0020 (this is the history dimension of 'verifiable facts about what this endpoint runs') and shares the record-the-event spine with RFC 0026 (#58) and the dev-app-update-audit gap. Likely wants its own short RFC to pick the anchoring mechanism (on-chain vs re-anchored RTMR vs both). Files: proxy/deploy.py, proxy/audit.py, proxy/runtimes.py.
Unlabeled — needs a design call on the anchoring mechanism before build.
Gap
A relying party can verify what code an app runs right now (RFC 0020 / RFC 0015), but cannot get a trustworthy answer to 'what are ALL the code versions this URL has ever served?' Today the per-app history is weak:
EmitEvent(proxy/audit.py _extend_rtmr), but the RTMR resets on CVM reboot andrecover_all()(proxy/runtimes.py) never re-anchors the historical log. So the live quote vouches only for this boot's deploys; earlier versions live solely in the per-project audit jsonl — a mutable file on the daemon volume.deploy.py:if mode == 'attested'. Dev-mode windows, and any un-promote → re-promote cycle (the RFC 0026 debug path), are invisible._extend_rtmronlylog.warnings; the deploy succeeds even if it wasn't anchored — completeness isn't enforced.project.jsonis overwritten with only the current pin; the jsonl is the history.Contrast (why this is a real asymmetry)
The daemon's own code versions ARE anchored the strong way:
ComposeHashAdded/ComposeHashRemovedon the base-KMS AppAuth contract — permanent on Base, reset-proof, no trust in the operator. Tenant apps deserve the same 'provable version set ever' property.Ask
Give each app a durable, tamper-evident version ledger:
Relation
Completes RFC 0020 (this is the history dimension of 'verifiable facts about what this endpoint runs') and shares the record-the-event spine with RFC 0026 (#58) and the dev-app-update-audit gap. Likely wants its own short RFC to pick the anchoring mechanism (on-chain vs re-anchored RTMR vs both). Files:
proxy/deploy.py,proxy/audit.py,proxy/runtimes.py.Unlabeled — needs a design call on the anchoring mechanism before build.