Re: Integrity of the Newlib sources can't be validated; ideas for improvement

On Tue, 21 Apr 2026 at 22:34, John Scott <[email protected]> wrote:

>  ◦ Newlib commits and tags are almost never signed by anyone contributing.
> The current workflow of sending patches to the mailing list makes this
> impossible because emailed patches cannot preserve Git commit signatures. I
> sent a patch here two weeks ago and despite signing the commit on my own
> machine, it was discarded when doing git format-patch.


I'd expand a bit on this "makes this impossible" part. It's not impossible,
but the purpose of the signature is designed with another angle in mind:

Signature information in a Git commit object is tied to the committer
identity and serves the purpose of verifying the committer entity, not the
author. Even if the author and the committer is the same person, for
example, when you amend (or rebase) a (stack of) signed commit(s), the
committer information is overwritten to be your name, e-mail, the date of
the amend/rebase, and, if signing is enabled, your selected signature key,
while the authorship information stays intact (by default).
The only use of the signature in this case is to verify that the commit has
been made by the person at a specific point in time, i.e., that the commit
was not tampered with by overriding GIT_COMMITTER_… environment variables
to fake committer identity.
For example, on GitHub, if a project uses (or even enforces the use of,
using server-side Git hooks implemented on the service) the "pull request"
feature to merge patches into the repository, then the "Author" of the
patch will be the person who submitted the "pull request", but the
"Committer" will be "GitHub", using their signature key:

```
$ git log -1 --pretty=fuller --show-signature
commit <SHA>
gpg: Signature made <TIMESTAMP>
gpg:                using RSA key <HEX>
gpg: Good signature from "GitHub <[email protected]>" [full]
Merge: <SHA1> <SHA2>
Author: <NAME> <[email protected]>
AuthorDate: <TIMESTAMP>
Commit: GitHub <[email protected]>
CommitDate: <TIMESTAMP>
```

As far as I can grok Git's documentation and by poking around the internals
of libgit, there is no way to (mathematically correctly) verify that the
authorship of a commit came from a specific person. A committer (in this
sense, someone trusted with write (push) rights to a repository), could
always fake authorship of commits (by setting GIT_AUTHOR_… and calling 'git
commit' that way) and tie whatever in the "Author:" fields to their
otherwise valid signature.

This is the reason for what you observed, that your signature did not
survive from e-mail patch to the contents of the repository. In theory, it
could be possible (through the use of mailbox filters and maintainer
vigilance) to
  a) require signature on e-mails of patches submitted to the list (to
verify authorship of the patch),
  b) and, separately from this, the project (any project, not just newlib!)
could have their maintainers (who actually commit and push to the golden
repository) sign the commits as well.

But these are two, in a sense, air-gapped verifications that have no
interlocks between one another.
In many ways, this is warranted and actually a good thing: suppose you
submit a signed patch, which works fine, but after a lengthy review, no
longer applies for some triviality. The maintainer is capable and happy to
just resolve the merge conflict or a slight issue instead of doing a
"reject and resubmit" on the patch. In this case, the contents that make it
into the repository are actually not equal (mathematically, hash-wise,
etc.) to the patch that you submitted, not even if there were multiple
rounds of patch submissions, because the maintainer amended it "locally"
prior to submission.
(And, mathematically, sneaking in some backdoor or other malice is the same
act of "locally editing a patch" as a benevolent resolution of a merge
conflict would be.)

In my opinion, although this is a drive-by because we have very little
stake in newlib so far and I'm only observing :), a) could be hard to pull
off (although I never saw the administration capabilities of mailman lists)
and also a significant barrier to contribution (for example, I'm sending
this very mail from a GMail interface, and I have no idea where or how I
could sign an e-mail…); however, b) could be doable. Software support
exists for the b) case, and, as long as we can rely on the assumption that
a maintainer, prior to commit, has some ways of verifying the safety and
correctness of the patch, it would be enough for "trust".