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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1WnA27-0003xp-E1
for bitcoin-development@lists.sourceforge.net;
Wed, 21 May 2014 17:10:27 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.223.170 as permitted sender)
client-ip=209.85.223.170; envelope-from=laanwj@gmail.com;
helo=mail-ie0-f170.google.com;
Received: from mail-ie0-f170.google.com ([209.85.223.170])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WnA26-0003R9-HW
for bitcoin-development@lists.sourceforge.net;
Wed, 21 May 2014 17:10:27 +0000
Received: by mail-ie0-f170.google.com with SMTP id at1so2304603iec.1
for <bitcoin-development@lists.sourceforge.net>;
Wed, 21 May 2014 10:10:20 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.43.155.16 with SMTP id lg16mr19419414icc.65.1400692220628;
Wed, 21 May 2014 10:10:20 -0700 (PDT)
Received: by 10.64.22.168 with HTTP; Wed, 21 May 2014 10:10:20 -0700 (PDT)
In-Reply-To: <7B48B9D4-5FB0-42CA-A462-C20D3F345A9A@beams.io>
References: <CA+s+GJBNWh0Py9KB4Y+B19ACeHOygtkLrPw5SbZ0SrVs50pqvg@mail.gmail.com>
<7B48B9D4-5FB0-42CA-A462-C20D3F345A9A@beams.io>
Date: Wed, 21 May 2014 19:10:20 +0200
Message-ID: <CA+s+GJC8=OHmmF7fc-fT8fQDWE1uNcCS8-ELEKr0MjQ4CpbPBA@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: 1WnA26-0003R9-HW
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: Wed, 21 May 2014 17:10:27 -0000
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?
At least signed commits are easy to integrate into the current
development process with github - only a different way of merging has
to be used.
> I came across these when searching for a way to enable signing by default,
> e.g. a `git config` option that might allow for this. Unfortunately, there
> isn't one, meaning it's likely that most folks will forget to do this most
> of the time.
I'll remind people if they forget to do it, but I won't require it. As
you say, that would be an extra barrier, and I'm not suggesting this
because I to see people jumping through bureaucratic hoops.
But it is a pretty simple thing to do...
> If you're really serious about it, you should probably reject pull requests
> without signed commits; otherwise, signing becomes meaningless because only
> honest authors do it, and forgetful or malicious ones can avoid it without
> penalty.
This is not because I'm afraid of malicious authors, but because I
want to reduce the risk that github hacks would pose.
Something to watch for would be authors that normally sign pull
requests/merges and suddenly don't. Someone malicious may have gained
access to their github account. This just adds an extra layer of
protection.
Cheers,
Wladimir
|
