Commits which include encoding header fail to verify when otherwise valid

[logancollins]

Description

Hello! I'm an engineer on the Nova project, an IDE for the Mac. As a tiny bit of context that becomes important later, we use libgit2 for our Git integration.

We received a report that a user who utilizes SSH keys for commit signing was seeing those made in Nova as invalid in Gitea. After some diagnosis, we found that the Git CLI was showing them as valid, but not once pushed to Gitea. We were then able to replicate this same behavior in our testing instance of Gitea 1.21.8.

After looking deeper, it seems that the only difference between commits made with the Git CLI and Nova is that those from Nova/libgit2 include an encoding header in the commit object, set to UTF-8. As far as I've been able to determine, this is the default value from Git's spec, and presumably the Git CLI just never includes it for succinctness. libgit2, however, is including it always.

If we disable inclusion of that header, Gitea will validate the commits just fine, the same as those from the Git CLI.

I am not versed in Go code at all (so please forgive me!) but I think I've traced the issue to somewhere around this chunk of code. I'm guessing that either it's not considering any header name which it doesn't already handle (and thus is dropping them from the payload that is used for validation) or something similar.

If I've glossed over anything important, just let me know, and thank you to the maintainers for your time!

Gitea Version

1.21.8

Can you reproduce the bug on the Gitea demo site?

Yes

Log Gist

No response

Screenshots

Git Version

2.44.0

Operating System

Linux / Ubuntu in Docker

How are you running Gitea?

We are running the self-installable Gitea instance running in Docker for testing purposes. I am not sure what our reporting user's instance was running in, or whether it was a self-instance or a Cloud / Enterprise instance. If you need, I can have our support team reach out and ask.

Database

SQLite

[KN4CK3R]

Fixed in #30174