Found by the 10-persona audit (platform persona), reproduced.
$ varve attach-status --status st.dsse --layout layout
$ python -c "…len(index['manifests'])" # deposit layout
3 # payload, envelope, line-status
$ varve archive 2026.08.0 arch
$ python -c "…len(index['manifests'])" # archive
2 # the line-status is gone
$ VARVE_ROOT=far varve install --from arch && VARVE_ROOT=far varve status
Distribution of line-status via the registry is tracked in REQ-STATUS-DIST-001 (…#34).
archive::export gathers payload + envelope + tool blobs and re-emits them via write_oci_layout. It does not carry the line-status referrer the layout held.
This defeats the purpose of REQ-STATUS-DIST-001. The reason a layer carries a baseline advisory at all is so a yank reaches a consumer who cannot contact a registry. The air-gapped consumer is precisely that consumer, and archive is precisely the route they use — so the one transport that needs the advisory most is the one that drops it. Their varve status is not temporarily unavailable; it is permanently broken for that layer, and the message points at a tracking issue rather than telling them what happened.
concept-deploy states that varve archive "writes the same OCI layout". It does not.
Fix: carry the line-status referrer through archive::export, and add a system test that attaches a status, archives, installs on the far side, and asserts varve status reports it. Note that the attestation carriage added in v0.26.0 already does exactly this for attestations — the line-status path was simply never given the same treatment.
Found by the 10-persona audit (platform persona), reproduced.
archive::exportgathers payload + envelope + tool blobs and re-emits them viawrite_oci_layout. It does not carry the line-status referrer the layout held.This defeats the purpose of REQ-STATUS-DIST-001. The reason a layer carries a baseline advisory at all is so a yank reaches a consumer who cannot contact a registry. The air-gapped consumer is precisely that consumer, and
archiveis precisely the route they use — so the one transport that needs the advisory most is the one that drops it. Theirvarve statusis not temporarily unavailable; it is permanently broken for that layer, and the message points at a tracking issue rather than telling them what happened.concept-deploystates thatvarve archive"writes the same OCI layout". It does not.Fix: carry the line-status referrer through
archive::export, and add a system test that attaches a status, archives, installs on the far side, and assertsvarve statusreports it. Note that the attestation carriage added in v0.26.0 already does exactly this for attestations — the line-status path was simply never given the same treatment.