summaryrefslogtreecommitdiff
path: root/04/39cbc61278ac947ab42c8a32e3123e63b3f5ae
blob: 737294e5b509845e98c646d655c8dee977ed6acb (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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <hozer@grid.coop>) id 1XL8Ws-000665-8p
	for bitcoin-development@lists.sourceforge.net;
	Sat, 23 Aug 2014 10:26:38 +0000
X-ACL-Warn: 
Received: from nl.grid.coop ([50.7.166.116])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1XL8Wc-0001hi-UF for bitcoin-development@lists.sourceforge.net;
	Sat, 23 Aug 2014 10:26:38 +0000
Received: from localhost (localhost [127.0.0.1]) (uid 1000)
	by nl.grid.coop with local; Sat, 23 Aug 2014 01:17:01 -0500
	id 000000000006E276.0000000053F831DD.00004D00
Date: Sat, 23 Aug 2014 01:17:01 -0500
From: Troy Benjegerdes <hozer@hozed.org>
To: xor <xor@freenetproject.org>
Message-ID: <20140823061701.GQ22640@nl.grid.coop>
References: <CAJHLa0NXAYh9HzazN6gArUV8y7J8_G0oqkZqPBgibpW0wRNxKQ@mail.gmail.com>
	<2302927.fMx0I5lQth@1337h4x0r>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
In-Reply-To: <2302927.fMx0I5lQth@1337h4x0r>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Spam-Score: 0.4 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.1 DATE_IN_PAST_03_06 Date: is 3 to 6 hours before Received: date
	-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 0.0 TIME_LIMIT_EXCEEDED    Exceeded time limit / deadline
X-Headers-End: 1XL8Wc-0001hi-UF
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering github
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: Sat, 23 Aug 2014 10:26:38 -0000

On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote:
> On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:
> > It would be nice if the issues and git repo for Bitcoin Core were not
> > on such a centralized service as github, nice and convenient as it is.
> 
> Assuming there is a problem with that usually is caused by using Git the wrong 
> way or not knowing its capabilities. Nobody can modify / insert a commit 
> before a GnuPG signed commit / tag without breaking the signature.
> More detail at the bottom at [1], I am sparing you this here because I suspect 
> you already know it and there is something more important I want to stress:
> 
> Bitcoin has currently 4132 forks on Github. This means that you can get 
> contributions by pull requests from 4132 developers. That is a HUGE amount, 
> and you shouldn't ditch that due to not using all features of git :)
> To get a grasp of how much that is: When you search projects with more than 
> 4100 forks, there are only 32 of them!
> You are one of the top open source projects, and you should be grateful for 
> that and keep Github up so the other people can send you pull requests with 
> their improvements :) Volunteer contributions need to be honored and made as 
> easy as possible, for people are investing their personal time.
> 
> Greetings and thanks for your work,
> 	xor, one developer of https://freenetproject.org
> 
> 
> [1] If you GPG-sign a commit / tag, you sign its hash, including the hash of 
> the previous commit. So is a chain of hashes and thus of trust from all 
> commits up to what is signed. It's pretty similar to the blockchain actually 
> :) 
> So Github cannot modify anything. If they did,  the head of the hash-chain 
> would change, and thus the signature would break. Git would notify people 
> about that when they pull. 
> Of course people can still ignore that warning and let Github rewrite their 
> Git history. But people who aren't educated about this shouldn't be release 
> managers. They should not even have push access to your main repository, they 
> should only be sending pull requests. Thats is where the decentralization of 
> Git is: In the pull-requests. The people who deal with them should verify tag 
> and possibly even commit signatures carefully, and not accept anything which 
> is not signed. Also, before deploying a binary, the very same commit which is 
> going to become a binary has to be given a signed tag by the release manager, 
> and by everyone who reviews the code. The person who deploys the actual binary 
> needs to verify that signature.
> There is an article which elaborates on some of the ways you have to ensure 
> Github doesn't insert malicious code - but please read it with care, some of 
> its recommendations are bad, especially the part where its about rebasing 
> because that DOES rewrite history which is what you want to prevent:
> http://mikegerwitz.com/papers/git-horror-story
> 
> 


This is why I clone git to mercurial, which is generally designed around the
assumption that history is immutable. You can't rewrite blockchain history,
and we should not be re-writing (rebasing) commit history either.

The problem with github is it's too tempting to look at the *web page*, which 
is NOT pgp-signed, and hit the 'approve' button when you might have someone
in the middle approving an unsigned changeset because you're in a hurry to
get the latest new critical OpenSSL 0day security patch build released.

We need multiple redundant 'master' repositories run by different people in
different jurisdictions that get updated on different schedules, and have all
of these people pay attention to operational security, and not just outsource
it all to github because it's convenient.


There's no reason to *stop* using github, cause it *is* easy... but you want
to have multiple review of *the actual code*, not just signatures and see 
if the changes really do make sense.

-- 
----------------------------------------------------------------------------
Troy Benjegerdes                 'da hozer'                  hozer@hozed.org
7 elements      earth::water::air::fire::mind::spirit::soul        grid.coop

      Never pick a fight with someone who buys ink by the barrel,
         nor try buy a hacker who makes money by the megahash