core: sign_lifecycle inherits created_by_device from the chain head while signing with the current device, so any continuation by another device fails verify_asset

[justin13888]

What the code does

capsule-core/src/lifecycle/provenance.rs, Workspace::sign_lifecycle, builds every continuation manifest (delete, trash-restore, metadata-update) as:

let core = ManifestCore {
    action,
    prior_provenance_hash: prior,
    retention_until,
    metadata_blob_hash,
    timestamp: now_rfc3339(),
    client_version: self.client_version.clone(),
    ..base.clone()          // <- created_by_user AND created_by_device come from the chain head
};
core.sign(self.device_signer.as_ref(), album.write_tier_signer()?)

So the record is signed by the current device but attributed to the base manifest's device.

Why that does not verify

capsule-core/src/crypto/verify_asset.rs resolves the signature this way:

1. step 6 — directory.core.user_id != core.created_by_user → Reject(UnknownDevice);
2. directory.device(&core.created_by_device) → Reject(UnknownDevice) when absent;
3. step 8 — the device signature must verify under that entry's dsk_public.

design/cryptography/provenance.md states the same rule in words: "device_sig — hybrid Ed25519 + ML-DSA-65 by the uploading device's DSK", and design/web-upload.md:91 has the adopting client set created_by_user/created_by_device to "the adopter (the cryptographic author)", not to the original uploader.

So the pair names the signer of this record. Inheriting it is correct only while the writing device is the creating device:

Case	created_by_device	signer	verify_asset
same device continues	creating device	same	passes
second device of the same account continues	creating device	other device	BadDeviceSig
writer member (S-C51) continues the owner's chain	owner's device	member's device	UnknownDevice (member's device is not in the owner's directory) / BadDeviceSig

The multi-device case is not exotic — it is any user with a phone and a laptop.

Server-side consequence

POST /v1/albums/{album_id}/ops enforces invariant 7 (capsule-server/src/routes/ops.rs): created_by_device must be in the caller's published directory. A manifest built by today's sign_lifecycle from another device therefore also gets 400 error.upload.device_not_authorized — for its own, independent reason. The server refusal and the verify_asset refusal are the same underlying defect seen from two sides.

This is why the writer-member lifecycle path opened by S-C51 (#405, PR #458) has no client that can produce a manifest anything accepts. The server side is landed and documented; the client side is this.

What a fix has to decide

Which of the two readings is normative, and then make one place enforce it:

1. The signer is the author (what verify_asset, provenance.md and web-upload.md all say): sign_lifecycle should set created_by_user/created_by_device from self.account / self.device_signer on every continuation, exactly as the three create paths already do (lifecycle/import.rs:465, lifecycle/drops.rs:305, drop/mod.rs:500). Then the chain records who made each change, which is what design/cryptography/provenance.md's "Provenance of Library Modifications" describes ("Every modification ... produces a provenance record — timestamp, device, client version, action").
2. The creator is the author and a separate pair names the writer: then verify_asset must resolve the signature against the writer's directory, the manifest needs the extra fields, and it is a schema change under a new protocol_version.

(1) needs no wire change and is what every doc in the tree already says. It is almost certainly the answer, but it changes what a stored chain means, so it should be decided explicitly rather than by patch.

Tests that should exist either way

• capsule-core: a second device of the same account continues a chain; assert verify_asset accepts.
• capsule-core: a writer member continues another account's chain; assert whatever the decision makes correct.
• capsule-server: tests/ops.rs currently constructs its member-write envelope by hand and cannot catch this; once core can produce a real continuation, that case should be driven from a real signed manifest.

Refs #405. Found while addressing the review of PR #458.

[justin13888]

The core half is fixed in PR #458

capsule-core/src/lifecycle/provenance.rs — sign_lifecycle now re-mints created_by_user and created_by_device per write from the acting account and signing device, instead of inheriting them from base via ..base.clone(). That is reading (1) from "What a fix has to decide" above: the signer is the author, which is what verify_asset steps 6–8 require and what provenance.md and web-upload.md:91 already said. No wire change, no protocol_version bump.

The field docs in capsule-core/src/crypto/provenance/manifest.rs are corrected from "User who produced the asset" to what the verifier requires, citing the step 6–8 coupling and naming where the original creator is recoverable — the create record at the head of the append-only chain.

Album authority is unaffected, as this issue predicted: it rides write_sig under the epoch's write-tier key at step 10, so naming the acting member as the record's author takes nothing from the owner.

Tests

Both cases this issue asked for now exist in lifecycle::provenance::tests and both fail if the inheritance is restored:

• a_continuation_from_a_second_device_names_it_and_verifies — the ordinary two-device case;
• a_members_continuation_verifies_under_the_members_own_directory — a shared album's member, verified against the member's own directory with the owner's album authority.

Worth recording: no existing test had to move. Nothing in the tree asserted the inherited-field behaviour, which is how it survived.

The server-side case this issue mentions (capsule-server/tests/ops.rs driving a real signed manifest) is still built from a hand-written envelope projection — that surface never parses manifest_cbor, so a server test needs the projection, not a signed manifest. The envelope it sends now matches what the fixed builder emits, and POST /v1/albums/{album_id}/ops checks created_by_user == caller again as a result.

What remains open here

Chains already written with an inherited device id. A record produced by an older client from a second device names a device that did not sign it and stays unverifiable at that record; this PR adds no migration. Nothing server-side reads it — the server never parses a manifest — so it is a client-side repair, and it needs someone to decide what a client should do when it walks a chain and finds one (quarantine the record? accept the chain up to it? re-sign?). Leaving this issue open for that.

[justin13888]

Follow-up from the confirming review of the core fix: the residual is wider than "that one record stays unverifiable," and the blast radius matters for whichever client-side repair is chosen.

verify_asset step 11 (capsule-core/src/crypto/verify_asset.rs:170-176) requires prior_provenance_hash == local_chain_head exactly, and sync_apply.rs:219-234 returns Quarantined without advancing local state on any terminal reject. So for a chain that already contains a record written by the old sign_lifecycle, the record itself fails at step 8 (BadDeviceSig) and every later record in that asset's chain then fails too, at step 11 (ForgedChain), because the local trusted head can never advance past the bad record. A receiving device does not flag one record and carry on — it stalls that asset permanently at the point of first inheritance.

Two consequences for the design decision this issue still owes (quarantine in place / re-sign / accept-with-gap):

• The cost is the whole tail of the chain from the first inherited record onward, not a single record, so "accept-with-gap" and "re-sign" differ from "quarantine" by much more than they appear to.
• BadDeviceSig and ForgedChain are also exactly what a real forgery or replay produces. From the verdict alone, a chain stalled by this bug is not distinguishable from a chain under attack — so whatever repair is chosen, an operator or a client needs some other signal to tell the two apart, and today there is none.