diff --git a/spec/SPEC.md b/spec/SPEC.md index dddc863a..c20e260a 100644 --- a/spec/SPEC.md +++ b/spec/SPEC.md @@ -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. ---