From: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
To: Alejandro Colomar <alx@kernel.org>
Cc: Jeff King <peff@peff.net>, git@vger.kernel.org
Subject: Re: git-send-email: Send with mutt(1)
Date: Thu, 9 Nov 2023 12:59:23 -0500 [thread overview]
Message-ID: <5yn2w52iymgnobesoi2jdwpyzaf5foc4sytxfdzl4vavlox62j@7att57ya6scz> (raw)
In-Reply-To: <ZU0aAQhVj7BQwr0q@debian>
On Thu, Nov 09, 2023 at 06:42:19PM +0100, Alejandro Colomar wrote:
> 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.
Well, sending is only a small part of what b4 will do for you -- the core
benefits are really cover letter management, automatic versioning and
simplified list trailer collection. It's all tailored to kernel needs, but it
will work for any project that depends on mailed patches.
> 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.
Well, no, it signs the entire thing, not just the patch, but it's true that
it's specifically targeted at patches (hence the name).
> 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.
Yes, but that's a feature.
> 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.
I go into this in the FAQ for patatt:
https://github.com/mricon/patatt#why-not-simply-pgp-sign-all-patches
Basically, developers really hated getting patches signed with PGP, either
inline or MIME, which is why it never took off. Putting it into the header
where it's not seen except by specialized tooling was a design choice.
> 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.
Right, the goal was really *just* attestation. For encrypted patch exchange we
have remail (https://korg.docs.kernel.org/remail.html), which worked
significantly better than any other alternative we've considered.
> 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.
Also true -- patatt was really envisioned as a library for b4, where you can
configure patch signing in your ~/.gitconfig for all projects.
-K
next prev parent reply other threads:[~2023-11-09 17:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 11:14 git-send-email: Send with mutt(1) Alejandro Colomar
2023-11-07 17:48 ` Jeff King
2023-11-07 18:36 ` Alejandro Colomar
2023-11-07 20:16 ` Jeff King
2023-11-08 21:02 ` Alejandro Colomar
2023-11-08 21:27 ` Jeff King
2023-11-09 15:26 ` Alejandro Colomar
2023-11-09 16:08 ` Konstantin Ryabitsev
2023-11-09 17:42 ` Alejandro Colomar
2023-11-09 17:59 ` Konstantin Ryabitsev [this message]
2023-11-10 21:06 ` Alejandro Colomar
2023-11-09 18:03 ` Jeff King
2023-11-09 23:00 ` Alejandro Colomar
2023-11-10 0:51 ` Alejandro Colomar
2023-11-10 13:30 ` Alejandro Colomar
2023-11-10 21:41 ` Jeff King
2023-11-10 23:31 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5yn2w52iymgnobesoi2jdwpyzaf5foc4sytxfdzl4vavlox62j@7att57ya6scz \
--to=konstantin@linuxfoundation.org \
--cc=alx@kernel.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).