Re: git-send-email: Send with mutt(1)

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3697 bytes --]

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 #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]