Re: git-am applies commit message diffs

From: Matthias Beyer <mail@beyermatthias.de>
Date: Feb 6, 2026, 08:18 UTC
Message-ID: <hn6q2mdjdqezzvtxfxffmatctnlf4ttvwedfk7wnw7xw75gy4g@hetctv53f7bh>
In-Reply-To: <CA+P7+xqcBcV8uySGgDfvt2ruAnFmfgaUy6aRbUC2zCzmCgPubw@mail.gmail.com>

Hi,

CCing some git-am contributors, hope that's alright for you!

On Fri, Feb 06, 2026 at 12:04:54AM -0800, Jacob Keller wrote:

Show 31 quoted lines

> On Thu, Feb 5, 2026 at 11:50 PM Matthias Beyer <mail@beyermatthias.de> wrote:
> >
> > Hi,
> >
> > I am not sure whether this was already reported, searching the lore did
> > not yield anything for me, but I might have overlooked it...
> >
> > This was just posted on mastodon[0]:
> >
> >     PSA: Did you know that it’s **unsafe** to put code diffs into your commit messages?
> >
> >     Like https://
> >     github.com/i3/i3/pull/6564 for example
> >
> >     Such diffs will be applied by patch(1) (also git-am(1)) as part of the code change!
> >
> >     This is how a sleep(1) made it into i3 4.25-2 in Debian unstable.
> >
> > TL;DR: If you put a diff in the commit message, that diff will be
> > applied by git-am.
> >
> > This looks clearly like unintended and might be an attack-vector, right?
> >
> 
> It is certainly surprising. I am not certain I would consider it an
> attack-vector since you should definitely be reading the commit
> messages before applying, but I could see the fact that its
> unintentional is a problem.
> [...]
>
> > [0]: https://mas.to/@zekjur/116022397626943871

As per the issue linked in that toot I quoted above, the issue clearly seems to be that it is not intentional that a diff embedded in the commit message will be applied. Nobody ever guessed that and that `sleep 1` that was in the commit message made it into debian unstable because people assumed it to work as intended.

I call that sheer luck, that it was only a `sleep 1` and not a "here is how I made this into a backdoor and here is a patch to fix it", ultimately getting the backdoor in which was written as a diff in the commit message, instead of the "fix" in the "patch part" of the email.

That said, I am no expert in either C or the git codebase at all, but from what I saw from reading the git-am codebase, it looks like it tries to find the patch by looking for three dashes on a line with a linebreak behind ("---\n"). From what I read, it looks for that from the first line. What I would think of here is looking for that "patchbreak" from the _end_ of the email rather than from the top, that would have prevented this issue, right?

Best, Matthias