linux-kernel - Re: email as a bona fide git transport

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: <56664222-6c29-09dc-ef78-7b380b113c4a@oracle.com>
Date:   Fri, 18 Oct 2019 16:27:48 +0200
From:   Vegard Nossum <vegard.nossum@...cle.com>
To:     Santiago Torres Arias <santiago@....edu>, Willy Tarreau <w@....eu>
Cc:     workflows@...r.kernel.org, Git Mailing List <git@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Konstantin Ryabitsev <konstantin@...uxfoundation.org>,
        Eric Wong <e@...24.org>
Subject: Re: email as a bona fide git transport


On 10/16/19 4:45 PM, Santiago Torres Arias wrote:
> Hi Willy, Vegard.
> 
> On Wed, Oct 16, 2019 at 01:10:09PM +0200, Willy Tarreau wrote:
>> Hi Vegard,
>>
>> On Wed, Oct 16, 2019 at 12:22:54PM +0200, Vegard Nossum wrote:
>>> (cross-posted to git, LKML, and the kernel workflows mailing lists.)
>>>
>>> Hi all,
>>>
>>> I've been following Konstantin Ryabitsev's quest for better development
>>> and communication tools for the kernel [1][2][3], and I would like to
>>> propose a relatively straightforward idea which I think could bring a
>>> lot to the table.
>>>
>>> Step 1:
>>>
>>> * git send-email needs to include parent SHA1s and generally all the
>>>    information needed to perfectly recreate the commit when applied so
>>>    that all the SHA1s remain the same
>>>
>>> * git am (or an alternative command) needs to recreate the commit
>>>    perfectly when applied, including applying it to the correct parent
>>>
>>> Having these two will allow a perfect mapping between email and git;
>>> essentially email just becomes a transport for git. There are a lot of
>>> advantages to this, particularly that you have a stable way to refer to
>>> a patch or commit (despite it appearing on a mailing list), and there
>>> is no need for "changeset IDs" or whatever, since you can just use the
>>> git SHA1 which is unique, unambiguous, and stable.
> 
> I wonder if it'd be also possible to then embed gpg signatures over
> send-mail payloads so as they can be transparently transferred to the
> commit.
> 
> -Santiago
> 

I just played a bit with this and with my proposed patch for
git-format-patch the signature is already part of the output:

$ ./git-format-patch --complete HEAD^-
0001-format-patch-add-complete.patch

$ cat 0001-format-patch-add-complete.patch
 From ac30b08065cd55362a7244a3bbc8df3563cefaaa Mon Sep 17 00:00:00 2001
From: Vegard Nossum <vegard.nossum@...cle.com>
Date: Sat, 5 Oct 2019 16:15:59 +0200
Subject: [PATCH] format-patch: add --complete

Include the raw commit data between the changelog and the diffstat.
This will allow 'git am' to reconstruct the commit exactly to the point
where the sha1 will be the same.

Signed-off-by: Vegard Nossum <vegard.nossum@...cle.com>
---
commit ac30b08065cd55362a7244a3bbc8df3563cefaaa
tree 8f09d9d6ed78f8617b2fe54fe9712990ba808546
parent 108b97dc372828f0e72e56bbb40cae8e1e83ece6
author Vegard Nossum <vegard.nossum@...cle.com> 1570284959 +0200
committer Vegard Nossum <vegard.nossum@...cle.com> 1571408340 +0200
gpgsig -----BEGIN PGP SIGNATURE-----
  Version: GnuPG v1

  iQIcBAABAgAGBQJdqcnVAAoJEAvO9Nj+mLpYPEMP/0qyUF6U9y6FMM3BQrjteGGY
  IEEwmkvfW8vMBdjXRjmSI1jxRUuW+xJs3kxezNuW79Gzkl63PlS3CdW50yLlWau6
  2gU4R8oSNr7vxpgfAscELxaAuvUSp7Vb1FEPc5kPW06Sprg4PkLkUMD71ALRnGMV
  TxTVMDbMYg2xHpwBFs1ZyF2l0ElqOvRqoQqYfvRql1rgbs5LhF0RevkIN5xswj93
  3Gz1CuB8MURX2lfglfYSTy/05Rx3w/QHxwNlbbPDtXrexySf+a70j/Z6i2/BIzR/
  kxlZJ/k4ZPN931mxFcLPBsV/K51uP378oEH1QdaZyO2jz1rj+AZxXlgXe8J3ZAmt
  XYT/FMze5lukd7EQDO5vPZazp1dnJ6wnmrAd8shCSWe23vybDMCYnjXTuwAXwbA5
  R7ffKxm3MwRn9LKsbHFiV0J8tS1/fHbOIEXQDJ+kFhKqys0RSXipDZU61LnogXaw
  827TcsUYLvkYlQ+LdmSjZ537E+bUTo3Udb/UkGbgwSSm9LTjHnAI34S6dxSZ+1cl
  jBD54v8u9I1hEImWxGbXns7ET1fh17Z4PoTPpA4COt3puAQY7vB7inGY3/kWz+7z
  iRieHyD/W6lba4rqNYHBxacD4JTXN9S9Z7o6F4ijeGQThbA77RWD64SGjuJM0mC7
  mGUqvHz0pn7zOl1ZOS26
  =gCT0
  -----END PGP SIGNATURE-----

---
  builtin/log.c | 12 ++++++++++++
  log-tree.c    | 17 +++++++++++++++++
  revision.h    |  3 ++-
  3 files changed, 31 insertions(+), 1 deletion(-)

diff --git a/builtin/log.c b/builtin/log.c
index c4b35fdaf9..81c1164ae5 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -1545,6 +1545,7 @@ int cmd_format_patch(int argc, const char **argv, 
const char *prefix)
[...]

There is no corresponding support in 'git am' yet, however.

Seeing how large this signature is, I have to admit that I am partial to
Konstantin's suggestion of using minisign. This seems like something
that could be added to git as an alternative to gpg without too much
trouble, I think.


Vegard