Skip to content

spec: bind signature mode to the signer allowlist in the normative text #645

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
MongLong0214 merged 1 commit into from
Aug 14, 2026
+2 −2
Merged

spec: bind signature mode to the signer allowlist in the normative text #645

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions spec/SPEC.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -233,9 +233,9 @@ Records are graded on two axes, and the grade decides how `Warn:` is delivered:

`Warn:` renders as an **instruction** only when provenance is `authored`, the record is active, and the commit's author string matches a string this repository configured for directives. Otherwise it renders as a **claim** — surfaced as information, never as a directive. In the default mode this is an unauthenticated, forgeable string match: the commit author chooses the string, so anyone able to write a commit can choose a configured one. A record from a contributor whose chosen string does not match renders as a claim; the match itself does not prove who wrote it.

`commitlore.requireSignedDirective=true` adds an opt-in authenticated boundary: an otherwise eligible directive additionally needs Git's `G` signature status, meaning Git verified it against the verifier's own trust store. Every other status — untrusted, bad, absent, expired, revoked or unable to check — is unverified and renders as a claim. A verified signature establishes neither the signer's authority to direct this repository nor the truth or safety of the record's content.
`commitlore.requireSignedDirective=true` adds an opt-in authenticated boundary: an otherwise eligible directive additionally needs Git's `G` signature status — meaning Git verified it against the verifier's own trust store — **and** the exact signing-key fingerprint Git reports as `%GF` must appear in the repository-local `commitlore.trustedSigner` allowlist. Every other signature status — untrusted, bad, absent, expired, revoked or unable to check — is unverified and renders as a claim, as does any fingerprint the allowlist does not list. An absent, empty, or unreadable allowlist authorizes nobody, so every record renders as a claim; it never means every valid signer is authorized. A verified signature establishes that a key this verifier accepts signed the commit; the allowlist is what supplies authority for this repository, and neither establishes the truth or safety of the record's content.

This is a minimum, not a solution: the default makes a repository's policy auditable rather than silently assumed, while signature mode uses Git's existing verifier trust store without inventing key distribution.
This is a minimum, not a solution: the default makes a repository's policy auditable rather than silently assumed, while signature mode uses Git's existing verifier trust store and a repository-local allowlist without inventing key distribution.

---

Expand Down
Loading