Registry build-record JSON unparseable: missing field 'classical' — L4 file integrity silently skipped

[emooreatx]

What

On a fresh CIRIS-Agent Android debug install (emulator, network up), every registry build-record fetch fails to parse and L4 file integrity is skipped:

WARNING - ciris_verify - [ciris_verify_core::validation] HTTPS query failed: HTTPS error: JSON parse error: Failed to read JSON: missing field `classical` at line 1 column 3963
ERROR   - ciris_verify - [ciris_verify_core::unified] VERIFY MANIFEST_CACHE MISS: No cached build record available and registry unreachable — L4 file integrity will be skipped
WARNING - ciris_verify - [ciris_verify_core::unified] VERIFY STEP 2/6 COMPLETE: FAILED (HTTPS error: No build record available (pre-fetch failed))
WARNING - ciris_verify - [ciris_verify_core::unified] VERIFY STEP 3/6 COMPLETE: FAILED (HTTPS error: No build record available (pre-fetch failed))

Read

The registry IS reachable (HTTPS succeeds; the body parses up to column 3963) — the record's signature block appears to have moved to a shape without the classical field verify's deserializer requires (hybrid-signature schema drift between the registry's current build records and verify's expected struct). Verify then reports "registry unreachable", which mislabels a schema mismatch as a network failure.

Impact

• L4 file integrity silently skipped on every boot for clients with this verify build (observed via qa_runner mobile pull-logs, CIRIS-Agent branch wt/client-catchup-0586, 2026-07-08).
• The WARNING/ERROR mix + "unreachable" wording hides that this is a compatibility break, not an outage.

Asks

1. Tolerant deserialization of the registry build-record signature block (accept records with and without classical — serde default/alias), so a registry schema bump doesn't zero out L4 for fielded clients.
2. Distinguish "registry unreachable" from "record unparseable" in the log line — the current message sent us diagnosing network first.
3. Confirm which side drifted (registry record schema vs verify struct) and whether fielded verify versions need a floor bump in the agent's pin.

Found during CIRIS-Agent 0.5.86 client catch-up QA (announce-first wizard run on Android emulator). Log bundle retained; happy to attach the full incidents_latest.log on request.

🤖 Generated with Claude Code

[emooreatx]

Resolved approach (operator, 2026-07-08): pure CEG-native, no new key bake.

The canonical server identity (ciris-canonical-1, persist v13.4.1/#393) is separate from the CI build-signing key, which doesn't exist yet. Key realization: verify already pins the accord holders A1/B1/C1 (accord_holder_bootstrap_anchor(), #160), so a build manifest signed by an A1-delegated CI key roots to a trust anchor verify already ships — nothing new to bake here.

The two external enablers (both on CIRISServer, since registry is folding in):

• CIRISServer#193 — mint the A1-delegated CI signing key + grant (the sign leg).
• CIRISServer#192 — serve the SignedCegObject build manifest + file manifest (the serve leg).

Verify-side work (this issue), once #193/#192 land:

1. Wire verify_build_manifest_contribution into unified.rs L1/L4 — granter_member = the baked accord anchor, pipeline_member = the CI key from the grant; retire the legacy BuildRecord/ResponseSignature fetch.
2. Log fix (independent, shippable now): distinguish 'registry unreachable' from 'record unparseable' — the current 'unreachable' wording mislabels a schema mismatch as an outage.

[emooreatx]

The canonical shape to publish/parse: SignedCegObject (ed25519/ml_dsa_65), NOT the legacy ManifestSignature.classical

Root cause confirmed as schema drift: the record moved to the CEG-native hybrid shape (no classical field), while the deserializer still expects the legacy ManifestSignature { classical, classical_algorithm, pqc, pqc_algorithm, key_id }. The canonical shape both sides should converge on is already defined in ciris_verify_core::ceg_outbox::SignedCegObject + ciris_verify_core::manifest_contribution — no new schema needed, just publish/parse this:

Outer — SignedCegObject (schema = "ciris.ceg.signed-object.v1"):

{
  "schema": "ciris.ceg.signed-object.v1",
  "kind": "build_manifest_contribution",
  "key_id": "<CI pipeline node key_id>",
  "created_at": "<RFC3339>",
  "body": { /* SignedEnvelope, below */ },
  "signatures": null
}

(signatures is null for a self-signed object — the signature lives inside body; the CegSignatures { ed25519, ml_dsa_65 } block is only for signed-request envelopes.)

body — SignedEnvelope (bound hybrid):

{
  "signed_envelope": { /* the manifest envelope */ },
  "ed25519_signature_base64": "<Ed25519 over JCS(signed_envelope)>",
  "mldsa65_signature_base64": "<ML-DSA-65 over JCS(signed_envelope) ‖ ed25519_sig>"
}

signed_envelope — the build-manifest Contribution:

{
  "attestation_type": "scores",
  "attesting_key_id": "<CI pipeline key_id>",
  "dimension": "provenance:build_manifest:<target>",
  "score": 1,
  "subject_key_ids": ["<build_id>"],
  "on_behalf_of": "<A1 human fed-id>",
  "delegation_scope": "infra:attest",
  "delegation_ref": "<A1→CI grant ref>",
  "build": { "target": "...", "binary_hash": "<sha256 hex>", "build_id": "...", "binary_version": "...", "manifest_hash": "<sha256 hex>" },
  "signed_at": "<RFC3339>"
}

Signing: everything over JCS (RFC 8785), bound-hybrid — Ed25519 over JCS(signed_envelope), ML-DSA-65 over JCS(signed_envelope) ‖ ed25519_sig. Constants: BUILD_MANIFEST_CONTRIBUTION_KIND, MANIFEST_PUBLISH_SCOPE = "infra:attest".

The producer already exists — manifest_contribution::sign_build_manifest_contribution(pipeline, build, on_behalf_of, delegation_ref, signed_at) -> SignedCegObject + .write_to_outbox(id) → <outbox>/build_manifest_contribution/<id>.json. The CLI can call it (or reproduce that body). Consumer side is verify_build_manifest_contribution → VerifiedManifest.

For ask #1 (tolerant deser) + #2 (distinguish unreachable vs unparseable): the parser should accept the SignedCegObject/SignedEnvelope shape above; the registry's records carrying classical are the old ManifestSignature writer and should be re-emitted through sign_build_manifest_contribution. On our side, CIRISServer#193 (A1-delegated CI key) + #192 (serve the SignedCegObject) produce records in exactly this shape.

[emooreatx]

Status (2026-07-12): the CEG-native manifest trust-root shape landed as the accord co-scrub — v9.0.0 / #185: verify_build_manifest_via_coscrub roots a build via the pipeline key's accord-co-scrubbed KeyRecord (infra:attest + ≥2 distinct anchors), retiring the legacy classical/pqc ResponseSignature + delegates_to-grant path this issue opened on (old verifier kept one release as a doc-only shim). The mint/serve legs also reshaped onto the co-scrub (CIRISServer#192/#193 → the /v1/accord/ci-key/{propose,cosign} endpoints + CIRISPersist#422).

Remaining verify-side piece (keeps this open): wire verify_build_manifest_via_coscrub into unified.rs L1/L4 so verify actually consumes the served manifest in the attestation flow (granter = the baked accord anchor). Gated on the serve leg (CIRISServer serving the SignedCegObject + the co-scrubbed pipeline record). Once that lands, L4 file-integrity stops silently skipping.