On 2025-10-16 at 18:57:57, James Bottomley wrote:

Now that mailinfo is updated to collect the message_id all the time,
use this in do_commit to add a "message-id" extra header containing
the message_id if it exists.  This means that git am will always
record the message-id if it can be found in the commit.  It will still
add it to the trailer if -m is specified, keeping the behaviour
backwards compatible.

This has most of the same downsides as the change ID header.

Yes, Message-IDs have to be globally unique, but sometimes they're not
due to implementation bugs.  It also allows tracking of changes which
may be a problem for privacy reasons, especially when it's always
enabled.  It's also a side channel where people can exfiltrate
information (e.g., cryptographic keys) without much visibility.

In addition, it is not guaranteed that message IDs are suitable for
inclusion.  They may be missing, malformed, or contain unacceptable
content (profanities, discriminatory content, EICAR test virus,
etc.)[0][1]. Silently inserting them into every commit without user
intervention, especially without a corresponding fsck check, is not a
good idea. Commit messages, author lines, and committer lines are at
least reasonably visible to the person applying the patch, but many mail
clients don't show the message ID by default or at all.

[0] You may think this is not a problem, but someone will do these
things if they can, possibly in a major project, because people are
inventive at causing chaos and we need to provide them fewer easy ways
to do so.  People already intentionally sow discord by pushing commits
with timestamps beyond 2^63, or even under 2^63 but beyond the expected
lifespan of our solar system, which then causes havoc when languages
like Ruby try to parse and interpret them.
[1] For instance, one of my servers is named "castro" (as in the San
Francisco neigbourhood, the Castro), but people, upon hearing the name,
are usually horrified to think that I've named my server for the Cuban
leader.  That name has ended up in many, many message IDs over the
years, and I know of still other much less savoury hostnames people have
used which will also necessarily appear in message IDs.
-- 
brian m. carlson (they/them)
Toronto, Ontario, CA