Hi Konstantin, On Thu, Nov 09, 2023 at 11:08:58AM -0500, Konstantin Ryabitsev wrote: > On Thu, Nov 09, 2023 at 04:26:23PM +0100, Alejandro Colomar wrote: > > I used it for sending a couple of patches to linux-man@, and it seems to > > work. I don't have much experience with mutt, so maybe I'm missing some > > corner cases. Do you expect it to not work for some case? Otherwise, > > we might have a winner. :) > > Since it's a Linux project, I suggest also checking out b4, which will do the > mail sending for you as part of the contributor-oriented features: > > https://b4.docs.kernel.org/en/latest/contributor/overview.html > > We also provide a web relay for people who can't configure or use SMTP due to > their company policies. > > > > > Would you mind adding this as part of git? Or should we suggest the > > > > mutt project adding this script? > > > > > > IMHO it is a little too weird and user-specific to really make sense in > > > either project. It's really glue-ing together two systems. And as it's > > > not something I use myself, I don't plan it moving it further along. But > > > you are welcome to take what I wrote and do what you will with it, > > > including submitting it to mutt. > > > > I'll start by creating a git repository in my own server, and will write > > something about it to let the public know about it. I'll also start > > requiring contributors to linux-man@ to sign their patches, and > > recommend them using this if they use mutt(1). > > B4 will also sign your patches for you. ;) I haven't yet tried b4(1), and considered trying it some time ago, but really didn't find git-send-email(1) and mutt(1) so difficult to use that b4(1) would simplify much. But still, I'll give it a chance. Maybe I see why afterwards. But I have tried patatt(1) before, which is what I think b4(1) uses for signing. Here are some of my concerns about patatt(4): It doesn't sign the mail, but just the patch. There's not much difference, if any, in authenticability terms, but there's a big difference in usability terms: To authenticate a given patch submitted to a mailing list, the receiver needs to also have patatt(1) configured. Otherwise, it looks like a random message. MUAs normally don't show random headers (patatt(1) signs by adding the signature header), so unless one is searching for that header, it will be ignored. This means, if I contribute to other projects, I need to tell them my patch is signed via patatt(1) in order for them to verify. If instead, I sign the email as usual with my MUA, every MUA will recognize the signature by default and show it to the reader. It also doesn't allow encrypting mail, so let's say I send some patch fixing a security vulnerability, I'll need a custom tool to send it. If instead, I use mutt(1) to send it signed+encrypted to a mailing list that provides a PGP public key, I can reuse my usual tools. Also, and I don't know if b4(1) handles this automagically, but AFAIR, patatt(1) didn't: fo signing a patch, I had to configure per-directory with `patatt install-hook`. I have more than a hundred git worktrees (think of dozens of git repositories, and half a dozen worktrees --see git-worktree(1)-- per repository). If I need to configure every one of those worktrees to sign all of my patches, that's going to be cumbersome. Also, I scrape and re-create worktrees for new branches all the time, so I'd need to be installing hooks for patatt(1) all the time. Compare that to having mutt(1) configured once. It doesn't scale that well. Cheers, Alex > > -K -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
