Hi Konstantin, On Thu, Nov 09, 2023 at 12:59:23PM -0500, Konstantin Ryabitsev wrote: > 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 would be interesting if MUAs would support PGP signatures in a header. Did you consider that option back then? Maybe patching a mutt(1) or neomutt(1) to do that would have been simpler than developing patatt(1). > > > 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. Overall, I think mutt(1) works better for me than patatt(1) via b4(1) for crypto operations. I don't use software that doesn't work with PGP/MIME, and it's more versatile. I'm still curious about the other features of b4(1), so I'll try it for those. Thanks! Alex > > -K -- <https://www.alejandro-colomar.es/>
Attachment:
signature.asc
Description: PGP signature
