On 2026-04-20 at 08:59:05, Kushal Das wrote:
> Hi all,
> 
> Every `git commit -S` since v2.45.0 produces a permanently-BAD
> signature when the commit message contains bytes that are not valid
> UTF-8 AND `i18n.commitEncoding` is unset (i.e. the default case).
> Verification fails under both `gpg --verify` and any non-GnuPG signer.
> The failure is deterministic: it happens every time, on every
> non-UTF-8 commit, no card or external tooling needed.

I'm not sure that's a valid configuration.  The commit message either
needs to be UTF-8 or you need to declare the encoding so Git can convert
it.

> My best guess is commit 6206089cbd0b1cb30a017ec904567f040ab4cea0 starting
> this (and I am maybe 100% wrong in identifying the cause).

It does bisect to that commit.  I wrote that patch originally, but it
got modified and sent upstream by someone else.  I'm not sure where it
got introduced, though.

> In pre-6206089cbd `commit_tree_extended`, `verify_utf8(&buffer)` ran
> BEFORE `sign_with_header(&buffer, sign_commit)`. `verify_utf8` is not
> a simple validator -- it mutates the strbuf in place, replacing
> invalid-UTF-8 bytes with their Latin-1 -> UTF-8 two-byte form. The
> signer therefore saw the transcoded bytes, and the same transcoded
> bytes were then written to the object database. Signer and
> verifier agreed.

The fact that we have a function called `verify_utf8` that does more
than verify is a problem.  I'll send out a two-patch series in a minute
or two that first fixes that to be called `ensure_utf8` and then fixes
the issue.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA