From: Matthias Beyer Date: Fri, 06 Feb 2026 08:18:50 GMT Subject: Re: git-am applies commit message diffs Message-ID: In-Reply-To: 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: > On Thu, Feb 5, 2026 at 11:50 PM Matthias Beyer 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