identity: signing_key, a second pin for git commit signing (closes #453)

[vyskocilm]

Closes #453.

git signs with a different key than it authenticates with. [identity] had one key field and the stack below it was singular — policy.Identity.SSHKey, sshproxy.Proxy.pinned []byte, one IdentityFile — so a profile with ssh_mode = "agent-proxy" could push and could not sign. No spelling got both.

A signing key is typically NOT an authorized key. Granting signing does not grant push; granting push does not grant signing. One field cannot say that; two can.

What lands

• policy.Identity.SigningKey (signing_key), through CheckText, expandVars and the under-target symlink refusal ssh_key already gets. Both key paths now share one loop, not two copied blocks.
• sshproxy pins a SET. New([]PinnedKey, …), Proxy.pinned []pin, REQUEST_IDENTITIES advertises both, handleSign matches with containsBlob — every element compared, results OR'd, no early exit.
• Generated ~/.gitconfig AUTHORS user.signingkey, gpg.format = ssh, commit.gpgsign = true. GitKeyWhitelist stays three keys: a carried user.signingkey names a host path absent inside, and a carried commit.gpgsign = true then fails every commit with error: No private key found for public key "…" / fatal: failed to write commit object (measured, git 2.55.0).
• signing_key with ssh_mode = "none" refused at resolve time.
• Staged at ~/.ssh/id_snug_signing.pub, --ro-bind-data, second constant beside PubKeyGuest.

The startup probe, and why it is two phases

sshproxy.New asks the host agent, on ONE connection before the listener binds, whether it holds each pinned key — and for identity.signing_key, whether it will actually SIGN.

Phase 2 exists because the red team broke phase 1. Membership was not enough: a key can be LISTED and UNSIGNABLE with no state change at all. Measured, OpenSSH 10.5p1:

setup	REQUEST_IDENTITIES	SIGN_REQUEST
ssh-add -c <key>, no askpass	listed (type 12)	refused (type 5), 57 ms
ssh-add -h github.com <key>	listed (type 12)	refused, always

Both then failed EVERY commit inside, because snug authors commit.gpgsign = true. The -c case is the setup #453 itself describes — a signing key is frequently the one key in the agent authorised to push nowhere. The -h case can never work through snug at all: lifting the constraint needs session-bind@openssh.com, which handle refuses wholesale so ssh -A from inside cannot chain the agent onward. The refusal says that, rather than suggesting a retry.

Probe payload is snug-agent-probe\0 + 32 bytes crypto/rand, 49 bytes, fresh per key per run. Not replayable: SSHSIG blobs begin with the literal SSHSIG (git's own signing blob measured at 95 bytes starting 53 53 48 53 49 47) and this begins s; an SSH userauth signature's first four bytes are a session-id length, here reading 1936618855 against a 49-byte payload. Reply inspected and dropped — never stored, audited, written or relayed.

Flags are what git measurably sends, read from the blob's algorithm name: 0x0 ed25519, 0x4 (RSA_SHA2_512) for ssh-rsa. A probe succeeding with flags git will not use proves the wrong thing in both directions.

signProbeTimeout is 2 minutes, deliberately not the 5 s list deadline: an agent whose askpass took 8 s blocked 8.059 s and then SUCCEEDED, so the short deadline would abort exactly the case the probe exists to serve. A time.AfterFunc in internal/cli says why snug is waiting, after 2 s, on stderr only.

The auth key is NOT sign-probed. Its failure is Permission denied (publickey) against a generated ~/.ssh/config naming one key — attributable. Probing it would put a confirmation dialog in front of every snug start, including runs that never touch the network, which trains people to click through the dialog that is the whole point of -c. It is one line in internal/cli if that is wrong.

BEHAVIOUR CHANGE

Existing single-key profiles included: a run whose agent does not hold the pinned key now refuses at startup instead of failing at first push. The probe covers both keys in one exchange; the old asymmetry was the absence of any check, not a decision.

Residuals, stated not closed

• The agent protocol carries no purpose field. With both keys pinned, either key can be used for either job by anything inside. Two keys are two identities' worth of blast radius, not two compartments.
• The probe is startup state, not a guarantee. A key removed, an agent locked, or a confirmation declined after New returns fails at sign time as before.
• The signature is not verified cryptographically. The measured failure is an agent that REFUSES; an agent lying to its own user is not in the threat model.

Red team

Run before merge. One sev:medium (above) and two sev:low, all fixed in 41299c0, none ticketed:

• handleSign audited the success and stayed silent on an upstream REFUSAL — the human saw only git's agent refused operation?, which gitextract.go's own comment describes as reading like a host keyring fault. snug had the answer in reply[0].
• showIdentity was the only member of showCapabilities not using capRows, so the grant whose base.toml ABUSE line reads "SIGN COMMITS AND TAGS AS YOU" got four words in brackets while listen_names gets "THIS IS A SANDBOX ESCAPE". Both key rows now carry a consequence sentence.

Attacked and held: membership is the whole filter (one upstream contact per run, verified on the wire with a logging relay); a third key held by the agent never leaked into REQUEST_IDENTITIES, any error, or any timing; SSH_AUTH_SOCK pointed at a FIFO, a regular file and a directory all failed at connect(2) immediately — a FIFO does not hang the probe because connect is not open; 32767 claimed identities and a 300 KiB reply refused cleanly with no preallocation; forging runes in signing_key refused at resolve time; probe refusals left zero runtime dirs and no socket.

Four comments were FALSE as written after the fix and are repaired rather than annotated — including the one rendered into every sandbox's ~/.gitconfig.

Tests

make gate green. New: the finding itself (TestListedButUnsignableKeyRefusesTheRun, which also asserts os.Lstat(socketPath) is ErrNotExist — the ordering claim made observable from outside rather than asserted about line order), TestSignProbeCoversOnlyMustSignKeys, TestSignProbePayloadCannotBeReplayed, TestSignProbeSendsTheFlagsGitSends, TestSignProbeSignatureNeverLeavesNew, TestSignProbeDoesNotUseTheListDeadline, TestDryRunNeverAsksTheAgentToSign (with the positive control, without which it passes on a startIdentity that does nothing), TestCheckTextCoversEveryIdentityField (reflective — makes #454's walk a refactor rather than a security change), plus the pin-conflict, symlink, forging-rune and ssh_mode negatives.

Tests verified by mutation: disabling the phase-2 loop fails five of them; setting MustSign: false fails the dry-run control.

Two new goldens — no committed golden rendered an identity before this. The argv golden asserts the --ro-bind-data row for the staged signing key and that no argv line binds a host ~/.ssh path.

VERIFY.md §13a-2 is the by-hand equivalent, negatives included. Integration TestGeneratedGitconfigSignsACommit is written and unrun here — no sandbox guarantee in this environment.

Not in scope

Signature VERIFICATION. gpg.ssh.allowedSignersFile names a file of other people's keys — a different grant with a different abuse sentence (#453 point 5). GPG: no gpg-agent proxy, no single-blob-pin property.

🤖 Generated with Claude Code