Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XKuO4-0005sI-V7 for bitcoin-development@lists.sourceforge.net; Fri, 22 Aug 2014 19:20:36 +0000 X-ACL-Warn: Received: from smtprelay04.ispgateway.de ([80.67.31.38]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1XKuO3-0005Zv-8g for bitcoin-development@lists.sourceforge.net; Fri, 22 Aug 2014 19:20:36 +0000 Received: from [89.13.205.10] (helo=anonymous) by smtprelay04.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1XKuNw-0001U6-KZ for bitcoin-development@lists.sourceforge.net; Fri, 22 Aug 2014 21:20:28 +0200 From: xor To: bitcoin-development@lists.sourceforge.net Date: Fri, 22 Aug 2014 21:20:11 +0200 Message-ID: <2302927.fMx0I5lQth@1337h4x0r> Organization: Freenet Project User-Agent: KMail/4.13.2 (Linux/3.13.0-34-generic; KDE/4.13.2; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2097506.CLvD5aoBrR"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-Df-Sender: eG9yQGZyZWVtYWlsLmJvZ2VydC5kZQ== X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [80.67.31.38 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Headers-End: 1XKuO3-0005Zv-8g Subject: Re: [Bitcoin-development] Reconsidering github X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: xor@freenetproject.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:20:37 -0000 --nextPart2097506.CLvD5aoBrR Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 --nextPart2097506.CLvD5aoBrR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIbBAABCAAGBQJT95f5AAoJEMtmZ+8tjWt5feYP90ZqIqd6pgqfKK/eOmgfGwlD ha9HjcxBC9U2wB8ZaNwuXlMwjbKfIccpa5Sws1RgT1QFKfqHskPk3itJfF8bKMB+ A8K1z9NCXS6ryKV274ho1tIg4APlGy7jen2mbJxtG6w5Mj7q43d7dLgK3YvWphDw 577YyhcfeRBXuzgrSbswPbf8OKFJazIve0glRS8AlneaCPoGQTt5K/2aSsmILc9D qPrpG+er8F6pvpox8mEclEGPrsXI+fc4r+czvxl8KHodZbRPLobvxeVp7zgRaKhX A0XH8/HQUt48EkR+HGNXOyNtMfL8YQabX+nTBbOtUEDj/1uawFSMxmdspgR6Ovf8 hNLN0H3spdcpVNuFfyM2acOZlc4Q/hqPOcuBII0u66EUdXikwYrlgUCa5jHPt/PE dOLdWUCi7Wged1DVzljLG1/KHfVBS3kkmISKvaosQks3xqRy1o+XkREie2O3U3kl afEY2/+uvu3ZST85niSifakqzolWbpGBLxw+c5CwQYQ/M0XbsBwwCMFyfJhyjKJC RWYEoqv4ZSr+LqLsnXp+3SGIHm6HA5978fmD8tS06stBxZXymgJEBMhSmpRZQa/l EJUmVMRFd86IghiA3eDK5kyKruJujzDYqkOcC9klvggYv7GQvBcln0MxvdOGtMlK LbQlT6JEd6OsdC/wiTY= =Q8RI -----END PGP SIGNATURE----- --nextPart2097506.CLvD5aoBrR--