Codex review of the first attempt found both, and both were in the git plumbing
that my unit tests never touched -- they only exercised the pure predicate.
1. HIGH: git's `%s` is the first PARAGRAPH, not the first line. It joins
consecutive non-blank lines with spaces, so
`fix: harmless subject`
`This explains [decisions-edit] on line two.`
came back as ONE line containing the token and armed it -- the exact
false-arm this change exists to prevent. The first line is now taken from
`%B` via `subject_of()`.
2. HIGH: the in-band `\x1f`/`\x1e` field separators were injectable. A subject
containing a literal `\x1f` was split at the wrong place and its tail read as
a trailer, arming the token. Framing is now NUL, which git forbids inside a
commit message and which therefore cannot be injected, with exact-arity
parsing (fields must be a multiple of three) that refuses to arm otherwise.
Also from the same review:
- Refuse to arm on a `%(trailers:...)` atom echoed literally by a git older than
2.22, which would otherwise read as a non-empty trailer (exit 0, so `_run`
returns it rather than None).
- Record corrected: 38 subject-tokened commits in ancestry, not "twenty"; and it
no longer claims a blanket fail-safe -- `_token_armed` failing is safe, but the
surrounding `_diff_findings` fails open earlier on an unresolvable merge-base,
skipping every check. That predates this change.
Adds 8 integration tests that drive `_token_armed` against a real throwaway git
repo -- the gap that let both defects pass. Verified non-vacuous by
reconstructing the old implementation in memory: it arms on both inputs, the new
one does not.
Note `--format` uses git's `%x00` escape, not a literal NUL: a NUL in argv raises
ValueError from subprocess, which broke every diff-engine test until fixed.
timothy
243bec708d