Governance rejections log a key fingerprint, not the keydir identity #102

New issue

Closed

opened 2026-08-14 08:07:42 +00:00 by a73x · 1 comment

a73x commented

2026-08-14 08:07:42 +00:00

(Migrated from git.a73x.sh)

A refused request logs the principal as a fingerprint rather than the name rules are written against:

INFO  Public key auth accepted for key type ssh-ed25519 (key:SHA256:3aKblHwa…)
WARN  Rejected exec request: principal key:SHA256:3aKblHwa… may not create "/data/repos/eitri.git"

The authorization itself is correct — eitri.git does not exist and no rule grants create rights — and name resolution genuinely works: settings.git is granted to the bare name (RW+ = xanderle, not @all) and reads fine, so the enrolled identity does match rules.

But the operator reading that line has to map a fingerprint back to a person by hand, in the one message where knowing who was refused is the whole point. keydir/<name>.pub exists precisely so principals have names; governance.name_for() already resolved one during auth moments earlier.

Wanted: log the resolved identity, keeping the fingerprint alongside it for the case where a key authenticates but resolves to a surprising name — principal xanderle (key:SHA256:3aKblHwa…).

Second, smaller: "may not create" is a confusing way to say "that repository does not exist". It is accurate under wild-repo semantics — a push to an absent path is a create, and the refusal is of the create — but the common case is someone mistyping a name or assuming a repo was pushed here when it was not. This is what sent the user to ask whether the URL was even valid. Worth distinguishing "no such repository, and you may not create it" from "no such repository" where the rules would have allowed a create.

Both are messages that only matter when something is already wrong, which is when clarity is worth most. Found by reading the server log after a clone of a repository that does not exist here.

Migrated from git-collab issue 46c1bb64bb4c93787e64162f4fda5f3d820ce747.

Original author: a73x dev@a73x.sh.

Close reason: merged in patch 9de4ef4b

A refused request logs the principal as a fingerprint rather than the name rules are written against: ``` INFO Public key auth accepted for key type ssh-ed25519 (key:SHA256:3aKblHwa…) WARN Rejected exec request: principal key:SHA256:3aKblHwa… may not create "/data/repos/eitri.git" ``` The authorization itself is correct — `eitri.git` does not exist and no rule grants create rights — and name resolution genuinely works: `settings.git` is granted to the bare name (`RW+ = xanderle`, not `@all`) and reads fine, so the enrolled identity does match rules. But the operator reading that line has to map a fingerprint back to a person by hand, in the one message where knowing who was refused is the whole point. `keydir/<name>.pub` exists precisely so principals have names; `governance.name_for()` already resolved one during auth moments earlier. Wanted: log the resolved identity, keeping the fingerprint alongside it for the case where a key authenticates but resolves to a surprising name — `principal xanderle (key:SHA256:3aKblHwa…)`. Second, smaller: **"may not create"** is a confusing way to say "that repository does not exist". It is accurate under wild-repo semantics — a push to an absent path is a create, and the refusal is of the create — but the common case is someone mistyping a name or assuming a repo was pushed here when it was not. This is what sent the user to ask whether the URL was even valid. Worth distinguishing "no such repository, and you may not create it" from "no such repository" where the rules would have allowed a create. Both are messages that only matter when something is already wrong, which is when clarity is worth most. Found by reading the server log after a clone of a repository that does not exist here. --- Migrated from git-collab issue `46c1bb64bb4c93787e64162f4fda5f3d820ce747`. Original author: a73x <dev@a73x.sh>. Close reason: merged in patch 9de4ef4b

a73x commented

2026-08-19 10:19:12 +00:00

(Migrated from git.a73x.sh)

[claude 2026-08-19] Picking this up. Plan: (1) rebind key-session display principal to "{name} ({fingerprint})" on rejection/authorization lines, mirroring delegate sessions; (2) distinguish "no such repository, and may not create it" from plain "no such repository" in create-refusal logging; (3) instrument the tokio::spawn'd git subprocess future with the handler's span so subprocess errors are attributed. TDD via ServerHarness in tests/governance_test.rs.