archetech / archon / 35046717144

95%

push

github

fix(gatekeeper): Reject a backdated proof once the chain has committed the operation (#1145)

* fix(gatekeeper): Reject a backdated proof once the chain has committed the operation

An asset operation is authorized by the controller's document resolved at
the operation's own proof.created -- a timestamp the signer chooses. A key
rotated out of the controller can therefore name a created from before
the rotation and be authorized by the document that still listed it, so
rotation never revokes a leaked key's power over the agent's assets.
Demonstrated for the legacy and bound proof suites, and with the
controller registered and confirmed on chain: the chain orders the forgery
after the rotation and the gatekeeper accepts it anyway, because
authorization never consults that order (#1131).

Once a chain has committed an operation it has a position the signer did
not choose. controllerAt resolves the controller there instead: by ordinal
when controller and operation share a chain, since every event in a block
shares the block's time and only the ordinal orders a rotation against an
operation committed earlier in the same block (#1136); by time across
chains. An unanchored controller stamps its events with each node's clock,
so it falls back to proof.created rather than fork on import order, which
is what #1134 did. Threaded through import, the verify replay, and the
confirmation replace path -- which swapped in the confirmed twin without
re-verifying, and would have laundered a locally accepted forgery into
confirmed state. It is re-verified against the version it chained from,
as replay does; resolving at present would judge a self-update by the
document it produced.

The verdict must not depend on arrival order. Only the node's own registry
mediator can vouch that a chain committed an event, and it delivers block
by block; a relaying peer or an operator restoring an export can vouch for
neither the chain nor its order (an export is sorted by proof.create... (continued)

4216 of 4846 branches covered (87.0%)

Branch coverage included in aggregate %.

44 of 46 new or added lines in 2 files covered. (95.65%)

8846 of 9289 relevant lines covered (95.23%)

787.4 hits per line