@bert_hubert @Lot_ten Succes!

There's been a long nerd-sniping thread recently here from @monsieuricon where email message-ids were being discussed and generated in semi-interesting ways that ended up detouring me and @brauner into writing up competing python vs. perl scripts to get `git send-email` to properly use our new bespoke message ids:
https://social.kernel.org/notice/AU5IphRPUsQvvkx732

But why does any of this matter? As most everyone knows, Linux kernel development happens through email, and the Message-Id of an email is a unique identifier that is used to track messages in our patch handling tools and archives (see https://lore.kernel.org for the archives.) By crafting shorter-but-still-unique message ids it's easier to reference those messages in other places, and using words is just prettier overall than random UUID values (https://i.redd.it/64gl4t9s52ra1.jpg for an example)

Bonus to all of this is that people don't realize that most of the patches we send out are actually signed and can be validated as coming from the person that sent them. The tool we use for that looks at the body of the email, and a small subset of the Header tags in the email. By providing to the tool our custom Message-Id, that adds yet another portion of the email that is now able to be signed and validated, providing a tiny bit more security overall in the patch submission processes (very very tiny, I know, but it's real, as I found out when I submitted a patch with a broken message-id from what was signed and our tools caught it.)

Anyway, all of that is a long way of showing off a tiny core change to the kernel that allows some core structures to be moved to read-only memory that I've been working on for a few months now. Here's the last portion of that work being sucked off of the email archives and validated as coming from me:

@brauner @dakkar @monsieuricon
Ok, all now working properly, and bonus, the message-id is now part of the signature on the email itself!

@vbabka @brauner @dakkar @monsieuricon Yes, it's better than the "write once, and then rewrite again, and again, and again as the language updates itself and breaks previously-working scripts over the years" :)

@brauner @monsieuricon @dakkar Ah, makes sense.

Anyway, rewrote it in perl as that way I have a chance to maintain it over time: https://paste.sr.ht/~gregkh/d8cd98966d8e5ef61161c0341b250d018b16e8bd

@monsieuricon @brauner @dakkar Ah, so the python email library messed up again? Heck, if we are allowed to write full scripts here (and not just bash one-liners), let me try something on my own, worst case I write it in C...

@brauner @monsieuricon @dakkar better, thanks!

But (you knew there was a but)…

message ids no longer have <> characters: `Message-Id: 2023040228-pastor-evidence-1269@gregkh Is that intentional and still a valid message id? As @monsieuricon said, email parsing is rough.

@brauner @monsieuricon @dakkar Thanks!

In the never-ending series of things that really don’t matter but are fun, something is still not working. I just tried sending a patch out with this and the gmail server did not like it at all, and rewrote the message id with:

  Message-ID: <64293fdb.5d0a0220.58d3f.02e0SMTPIN_ADDED_BROKEN@mx.google.com>
X-Google-Original-Message-ID: <2023040245-stardust-obtain-0b4d@gregkh> usage.

Ah, in typing that out I see why, the original email header was:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
 usage.

So the perl script changed that to:

Subject: [PATCH] MIPS: vpe-cmp: remove module owner pointer from struct class
Message-Id: <2023040245-stardust-obtain-0b4d@gregkh>
 usage.

And then vger promptly ate the message and never delivered it to the mailing list. I’ll hand-edit the subject line to be one line for now to get stuff done, but be aware of this if you use it as-is.

@dakkar @monsieuricon @brauner yup, that worked, many thanks!

@dakkar @monsieuricon @brauner Debugging a embedded perl script in a bash script for git run to use to send email for a Linux kernel patch over a social media message is yak shaving at it's finest.

Unfortunately, no, this change did not work, let me go dig up my old perl book from the upstairs library...

@brauner @monsieuricon Much better. But not quite there, the script now strips out the "@" character and trailing text from the message id for some reason.

"2023040117-gem-unharmed-3194@gregkh" gets turned into "Message-Id: <2023040117-gem-unharmed-3194>"

But nice work with the inline perl, I have to use it for that reason alone!

@brauner @monsieuricon Ok, I lied, I couldn't resist doing it "by hand" to see if it would work, and it did: https://lore.kernel.org/lkml/2023040126-blandness-duckling-bd55@gregkh/

@brauner @monsieuricon Ok, you are forcing me to switch to use b4 for my development workflow now, fair enough :)

In the meantime, let me just send this bugfix patch out and stop messing around with pretty message-ids as the bugfix is probably more important in the short-term...

@brauner @monsieuricon ah, maybe you are using --thread on 'git format-patch'? That might get messy as the message ids are now not correct (you rewrote them), and --thread doesn't work on single patches

@brauner @monsieuricon Your git-hook doesn't seem to work for me as 'git format-patch' does not generate the message-id, git send-email does (when it is sending the message). Are you generating a message-id before you run 'git send-email' somehow?

@brauner @monsieuricon I was wondering about that...

Got the message id to work in mutt, will add it to git send-email tomorrow.

@brauner @monsieuricon Nice! I'm stealing that right now...

@brauner @monsieuricon I should at least try b4 out for new development. As @horms points out here:
https://lore.kernel.org/r/ZCU4BQ0C4K6HoBsf@corigine.com
I need all the luck I can get with my current "journey of a few hundred patches" that I'm on, and my current git branch / commit / rebase / rebase / rebase / rewrite / rebase / format-patch / send-email workflow leaves a lot to be desired at times.

@monsieuricon @brauner Cool! Now if only we could replace the hard-coded logic in `git send-email` with this...

@bagder This is one reason why the Linux kernel security team does not interact with the linux-distros list anymore, their policies just are not conclusive to keeping systems secure for users.