From: Jeff King <peff@peff.net>
To: Andrey Utkin <andrey.utkin@pb.com>
Cc: linux-kernel@vger.kernel.org, git@vger.kernel.org
Subject: Re: Don't use PGP/GPG signatures in mail that contains patches
Date: Mon, 18 Jan 2016 16:48:58 -0500 [thread overview]
Message-ID: <20160118214857.GA24136@sigill.intra.peff.net> (raw)
In-Reply-To: <569C3F73.3090805@pb.com>
On Mon, Jan 18, 2016 at 03:27:15AM +0200, Andrey Utkin wrote:
> ===== QUOTE =====
> Don't use PGP/GPG signatures in mail that contains patches.
> This breaks many scripts that read and apply the patches.
> (This should be fixable.)
> ===== END QUOTE =====
>
> This is in Linux' Documentation/email-clients.txt since 2007, and still
> almost nobody signs patch submissions. There are few brave people who
> do, though, and seems it's not the end of world for any "scripts".
> The broken scripts could be an excuse in 2007, but not today.
>
> Proposal:
> 1. Implement signing option in git-send-email.
> 2. Figure out if anything fails to interoperate.
> 3. Drop the quoted statement or change it to appreciate signing.
I don't know about other receiving scripts, but "git am" will handle
signed PGP-MIME out of the box (I didn't try it with inline signatures,
but I imagine it would stick the "BEGIN PGP MESSAGE" cruft into the
commit message).
However, there's an open question of what to _do_ with such a signature.
The email signature does not function as a valid git commit signature.
So you are left with one of:
1. The receiver can verify the origin of the email before applying the
patch.
2. The receiver can keep a copy of the email "somewhere", so people
can later re-verify it, and then hand-verify that it matches what
got applied.
That "somewhere" may just be a mailing list archive, but you could
get fancy with scripts and associate it with the applied commit
(e.g., using "git notes").
But those are really questions for the project. If you are mailing your
patches to Linus, does he actually care about (1)? My general impression
of his past opinion is that it's more important to read the patch text
than the "From" line. Of course subsystem maintainers and other projects
may have different opinions.
I think (2) is more compelling, if only to create a better record in the
mailing list archive. Assuming the receivers of your patches don't mind
(and I know some people really _don't_ like things like PGP-MIME,
because their mail readers are not good at replying in-line to the
patches then), I don't it would be a bad thing to teach git-send-email
an option to send it.
-Peff
next prev parent reply other threads:[~2016-01-18 21:49 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-18 1:27 Don't use PGP/GPG signatures in mail that contains patches Andrey Utkin
2016-01-18 21:48 ` Jeff King [this message]
2016-01-19 11:52 ` Andrey Utkin
2016-01-19 21:05 ` Eric Wong
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=20160118214857.GA24136@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=andrey.utkin@pb.com \
--cc=git@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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 NNTP newsgroup(s).