lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <569E2398.2050206@gmail.com>
Date:	Tue, 19 Jan 2016 13:52:56 +0200
From:	Andrey Utkin <andrey.od.utkin@...il.com>
To:	Jeff King <peff@...f.net>
Cc:	linux-kernel@...r.kernel.org, git@...r.kernel.org
Subject: Re: Don't use PGP/GPG signatures in mail that contains patches

On 18.01.2016 23:48, Jeff King wrote:
> 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.

Thank you for thoughtful reply!
Surely email submission signature cannot be used as git commit
signature. And surely there are issues of usability. And surely people
are used not to care.
But still, if we encourage signing maillist correspondence, we would
avoid impersonation attacks. Imagine that somebody sends stupid
submissions from your name, maintainers shout at you, and your
reputataion is... changed. Of course, you will be able to sort things
out after you read the replies and reply that it's not you. But, given
to openness of maillists, the attacker is able to follow your replies
and insert his ones. Or to reply to your valid submissions that they are
not from you.
Still it seems that making fun of that is not much harder than
masquerading on GitHub
(https://github.com/amoffat/masquerade/commit/9b0562595cc479ac8696110cb0a2d33f8f2b7d29)
Sure there are anti-spoofing measures like DKIM. Honestly I am not aware
if vger.kernel.org is so restrictive that it accepts only letters from
super-safe email servers, but I guess it is not, because not everybody
has this stuff configured on their email servers.


Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ