Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XL9zG-0004lx-Jt for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 12:00:02 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.52 as permitted sender) client-ip=209.85.216.52; envelope-from=gubatron@gmail.com; helo=mail-qa0-f52.google.com; Received: from mail-qa0-f52.google.com ([209.85.216.52]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1XL9yp-00054s-UB for bitcoin-development@lists.sourceforge.net; Sat, 23 Aug 2014 12:00:01 +0000 Received: by mail-qa0-f52.google.com with SMTP id j15so10810761qaq.11 for ; Sat, 23 Aug 2014 04:59:24 -0700 (PDT) X-Received: by 10.140.42.195 with SMTP id c61mr5952594qga.54.1408795164427; Sat, 23 Aug 2014 04:59:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.86.37 with HTTP; Sat, 23 Aug 2014 04:59:04 -0700 (PDT) In-Reply-To: <20140823061701.GQ22640@nl.grid.coop> References: <2302927.fMx0I5lQth@1337h4x0r> <20140823061701.GQ22640@nl.grid.coop> From: Angel Leon Date: Sat, 23 Aug 2014 07:59:04 -0400 Message-ID: To: Troy Benjegerdes Content-Type: multipart/alternative; boundary=001a113abef4564ba205014aaf28 X-Spam-Score: -0.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 (gubatron[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -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: 1XL9yp-00054s-UB Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Reconsidering github X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 12:00:02 -0000 --001a113abef4564ba205014aaf28 Content-Type: text/plain; charset=UTF-8 I think this is the only project where people are concerened wether commit messages are signed or not. Commit messages should be merged only upon their correctness, not their signature. I could care less if I receive a buggy patch that's signed. http://twitter.com/gubatron On Sat, Aug 23, 2014 at 2:17 AM, Troy Benjegerdes wrote: > 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 > > > > ------------------------------------------------------------------------------ > Slashdot TV. > Video for Nerds. Stuff that matters. > http://tv.slashdot.org/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > --001a113abef4564ba205014aaf28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is the only project where people are conceren= ed wether commit messages are signed or not.

Commit messages should = be merged only upon their correctness, not their signature.

I could = care less if I receive a buggy patch that's signed.



On Sat, Aug 23, 2014 at 2:17 AM, Troy Be= njegerdes <hozer@hozed.org> wrote:
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 i= t is.
>
> Assuming there is a problem with that usually is caused by using Git t= he wrong
> way or not knowing its capabilities. Nobody can modify / insert a comm= it
> 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 st= ress:
>
> Bitcoin has currently 4132 forks on Github. This means that you can ge= t
> contributions by pull requests from 4132 developers. That is a HUGE am= ount,
> 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 gratefu= l 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 m= ade as
> easy as possible, for people are investing their personal time.
>
> Greetings and thanks for your work,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0xor, one developer of https://freenetproject.org
>
>
> [1] If you GPG-sign a commit / tag, you sign its hash, including the h= ash of
> the previous commit. So is a chain of hashes and thus of trust from al= l
> commits up to what is signed. It's pretty similar to the blockchai= n actually
> :)
> So Github cannot modify anything. If they did,=C2=A0 the head of the h= ash-chain
> would change, and thus the signature would break. Git would notify peo= ple
> 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 repositor= y, they
> should only be sending pull requests. Thats is where the decentralizat= ion of
> Git is: In the pull-requests. The people who deal with them should ver= ify tag
> and possibly even commit signatures carefully, and not accept anything= which
> is not signed. Also, before deploying a binary, the very same commit w= hich is
> going to become a binary has to be given a signed tag by the release m= anager,
> and by everyone who reviews the code. The person who deploys the actua= l binary
> needs to verify that signature.
> There is an article which elaborates on some of the ways you have to e= nsure
> Github doesn't insert malicious code - but please read it with car= e, some of
> its recommendations are bad, especially the part where its about rebas= ing
> 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 design= ed around the
assumption that history is immutable. You can't rewrite blockchain hist= ory,
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 p= eople in
different jurisdictions that get updated on different schedules, and have a= ll
of these people pay attention to operational security, and not just outsour= ce
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=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0'da hozer'=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 hozer@hozed.org
7 elements=C2=A0 =C2=A0 =C2=A0 earth::water::air::fire::mind::spirit::soul= =C2=A0 =C2=A0 =C2=A0 =C2=A0 = grid.coop

=C2=A0 =C2=A0 =C2=A0 Never pick a fight with someone who buys ink by the ba= rrel,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nor try buy a hacker who makes money by t= he megahash


--------------------------------------------= ----------------------------------
Slashdot TV.
Video for Nerds.=C2=A0 Stuff that matters.
http://tv.slashdot.or= g/
_____________________________= __________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001a113abef4564ba205014aaf28--