summaryrefslogtreecommitdiff
path: root/a5/8c2329e5c2bbbf3ed91a792ff90850a7fdcc6c
blob: d297d9f7844648614c4e89244cf756a4f3b61606 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <laanwj@gmail.com>) id 1Wnmdk-0004kZ-I5
	for bitcoin-development@lists.sourceforge.net;
	Fri, 23 May 2014 10:23:52 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.223.175 as permitted sender)
	client-ip=209.85.223.175; envelope-from=laanwj@gmail.com;
	helo=mail-ie0-f175.google.com; 
Received: from mail-ie0-f175.google.com ([209.85.223.175])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Wnmdj-00015h-NE
	for bitcoin-development@lists.sourceforge.net;
	Fri, 23 May 2014 10:23:52 +0000
Received: by mail-ie0-f175.google.com with SMTP id y20so4846327ier.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 23 May 2014 03:23:46 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.50.50.231 with SMTP id f7mr2958900igo.42.1400840625976; Fri,
	23 May 2014 03:23:45 -0700 (PDT)
Received: by 10.64.22.168 with HTTP; Fri, 23 May 2014 03:23:45 -0700 (PDT)
In-Reply-To: <CA+s+GJC8=OHmmF7fc-fT8fQDWE1uNcCS8-ELEKr0MjQ4CpbPBA@mail.gmail.com>
References: <CA+s+GJBNWh0Py9KB4Y+B19ACeHOygtkLrPw5SbZ0SrVs50pqvg@mail.gmail.com>
	<7B48B9D4-5FB0-42CA-A462-C20D3F345A9A@beams.io>
	<CA+s+GJC8=OHmmF7fc-fT8fQDWE1uNcCS8-ELEKr0MjQ4CpbPBA@mail.gmail.com>
Date: Fri, 23 May 2014 12:23:45 +0200
Message-ID: <CA+s+GJD2B2LC2ssehvm+x-QUoXCsYMcp-1ctBko94XEw0dUzpg@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Chris Beams <chris@beams.io>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(laanwj[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1Wnmdj-00015h-NE
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] PSA: Please sign your git commits
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 23 May 2014 10:23:52 -0000

On Wed, May 21, 2014 at 7:10 PM, Wladimir <laanwj@gmail.com> wrote:
> Hello Chris,
>
> On Wed, May 21, 2014 at 6:39 PM, Chris Beams <chris@beams.io> wrote:
>> I'm personally happy to comply with this for any future commits, but wonder
>> if you've considered the arguments against commit signing [1]? Note
>> especially the reference therein to Linus' original negative opinion on
>> signed commits [2].
>
> Yes, I've read it. But would his alternative, signing tags, really
> help us more here? How would that work? How would we have to structure
> the process?

I think a compromise - that is similar to signing tags but would still
work with the github process, and leaves a trail after merge - would
be: if you submit a stack of commits, only sign the most recent one.

As each commit contains the cryptographic hash of the previous commit,
which in turns contains the hash of that before it up to the root
commit, signing every commit if you have multiple in a row is
redundant.

I'll update the document and put it in the repository.

Wladimir