path: root/0e/b3bd423b5ac1b5f870916b2df323a5d858899a

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 <gubatron@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CAJHLa0NXAYh9HzazN6gArUV8y7J8_G0oqkZqPBgibpW0wRNxKQ@mail.gmail.com>
	<2302927.fMx0I5lQth@1337h4x0r> <20140823061701.GQ22640@nl.grid.coop>
From: Angel Leon <gubatron@gmail.com>
Date: Sat, 23 Aug 2014 07:59:04 -0400
Message-ID: <CADZB0_ZP0XN53u4Ye+KLcOLr3zhwAxhCYCycRNZ4kcTqZ770Og@mail.gmail.com>
To: Troy Benjegerdes <hozer@hozed.org>
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 <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 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 <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 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

<div dir=3D"ltr">I think this is the only project where people are conceren=
ed wether commit messages are signed or not.<br><br>Commit messages should =
be merged only upon their correctness, not their signature.<br><br>I could =
care less if I receive a buggy patch that&#39;s signed.</div>

<div class=3D"gmail_extra"><br clear=3D"all"><div><a href=3D"http://twitter=
.com/gubatron" target=3D"_blank">http://twitter.com/gubatron</a><br></div>
<br><br><div class=3D"gmail_quote">On Sat, Aug 23, 2014 at 2:17 AM, Troy Be=
njegerdes <span dir=3D"ltr">&lt;<a href=3D"mailto:hozer@hozed.org" target=
=3D"_blank">hozer@hozed.org</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">

<div class=3D"HOEnZb"><div class=3D"h5">On Fri, Aug 22, 2014 at 09:20:11PM =
+0200, xor wrote:<br>
&gt; On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote:<br>
&gt; &gt; It would be nice if the issues and git repo for Bitcoin Core were=
 not<br>
&gt; &gt; on such a centralized service as github, nice and convenient as i=
t is.<br>
&gt;<br>
&gt; Assuming there is a problem with that usually is caused by using Git t=
he wrong<br>
&gt; way or not knowing its capabilities. Nobody can modify / insert a comm=
it<br>
&gt; before a GnuPG signed commit / tag without breaking the signature.<br>
&gt; More detail at the bottom at [1], I am sparing you this here because I=
 suspect<br>
&gt; you already know it and there is something more important I want to st=
ress:<br>
&gt;<br>
&gt; Bitcoin has currently 4132 forks on Github. This means that you can ge=
t<br>
&gt; contributions by pull requests from 4132 developers. That is a HUGE am=
ount,<br>
&gt; and you shouldn&#39;t ditch that due to not using all features of git =
:)<br>
&gt; To get a grasp of how much that is: When you search projects with more=
 than<br>
&gt; 4100 forks, there are only 32 of them!<br>
&gt; You are one of the top open source projects, and you should be gratefu=
l for<br>
&gt; that and keep Github up so the other people can send you pull requests=
 with<br>
&gt; their improvements :) Volunteer contributions need to be honored and m=
ade as<br>
&gt; easy as possible, for people are investing their personal time.<br>
&gt;<br>
&gt; Greetings and thanks for your work,<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0xor, one developer of <a href=3D"https://fre=
enetproject.org" target=3D"_blank">https://freenetproject.org</a><br>
&gt;<br>
&gt;<br>
&gt; [1] If you GPG-sign a commit / tag, you sign its hash, including the h=
ash of<br>
&gt; the previous commit. So is a chain of hashes and thus of trust from al=
l<br>
&gt; commits up to what is signed. It&#39;s pretty similar to the blockchai=
n actually<br>
&gt; :)<br>
&gt; So Github cannot modify anything. If they did,=C2=A0 the head of the h=
ash-chain<br>
&gt; would change, and thus the signature would break. Git would notify peo=
ple<br>
&gt; about that when they pull.<br>
&gt; Of course people can still ignore that warning and let Github rewrite =
their<br>
&gt; Git history. But people who aren&#39;t educated about this shouldn&#39=
;t be release<br>
&gt; managers. They should not even have push access to your main repositor=
y, they<br>
&gt; should only be sending pull requests. Thats is where the decentralizat=
ion of<br>
&gt; Git is: In the pull-requests. The people who deal with them should ver=
ify tag<br>
&gt; and possibly even commit signatures carefully, and not accept anything=
 which<br>
&gt; is not signed. Also, before deploying a binary, the very same commit w=
hich is<br>
&gt; going to become a binary has to be given a signed tag by the release m=
anager,<br>
&gt; and by everyone who reviews the code. The person who deploys the actua=
l binary<br>
&gt; needs to verify that signature.<br>
&gt; There is an article which elaborates on some of the ways you have to e=
nsure<br>
&gt; Github doesn&#39;t insert malicious code - but please read it with car=
e, some of<br>
&gt; its recommendations are bad, especially the part where its about rebas=
ing<br>
&gt; because that DOES rewrite history which is what you want to prevent:<b=
r>
&gt; <a href=3D"http://mikegerwitz.com/papers/git-horror-story" target=3D"_=
blank">http://mikegerwitz.com/papers/git-horror-story</a><br>
&gt;<br>
&gt;<br>
<br>
<br>
</div></div>This is why I clone git to mercurial, which is generally design=
ed around the<br>
assumption that history is immutable. You can&#39;t rewrite blockchain hist=
ory,<br>
and we should not be re-writing (rebasing) commit history either.<br>
<br>
The problem with github is it&#39;s too tempting to look at the *web page*,=
 which<br>
is NOT pgp-signed, and hit the &#39;approve&#39; button when you might have=
 someone<br>
in the middle approving an unsigned changeset because you&#39;re in a hurry=
 to<br>
get the latest new critical OpenSSL 0day security patch build released.<br>
<br>
We need multiple redundant &#39;master&#39; repositories run by different p=
eople in<br>
different jurisdictions that get updated on different schedules, and have a=
ll<br>
of these people pay attention to operational security, and not just outsour=
ce<br>
it all to github because it&#39;s convenient.<br>
<br>
<br>
There&#39;s no reason to *stop* using github, cause it *is* easy... but you=
 want<br>
to have multiple review of *the actual code*, not just signatures and see<b=
r>
if the changes really do make sense.<br>
<div class=3D"im HOEnZb"><br>
--<br>
---------------------------------------------------------------------------=
-<br>
Troy Benjegerdes=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0&#39;da hozer&#39;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 <a href=3D"mailto:hozer@hozed.org">hozer@hozed.org</a><br>
7 elements=C2=A0 =C2=A0 =C2=A0 earth::water::air::fire::mind::spirit::soul=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"http://grid.coop" target=3D"_blank">=
grid.coop</a><br>
<br>
=C2=A0 =C2=A0 =C2=A0 Never pick a fight with someone who buys ink by the ba=
rrel,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0nor try buy a hacker who makes money by t=
he megahash<br>
<br>
<br>
</div><div class=3D"im HOEnZb">--------------------------------------------=
----------------------------------<br>
Slashdot TV.<br>
Video for Nerds.=C2=A0 Stuff that matters.<br>
<a href=3D"http://tv.slashdot.org/" target=3D"_blank">http://tv.slashdot.or=
g/</a><br>
</div><div class=3D"HOEnZb"><div class=3D"h5">_____________________________=
__________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>

--001a113abef4564ba205014aaf28--