[Bitcoin-development] Reconsidering github

[Bitcoin-development] Reconsidering github

[Jeff Garzik]

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.

To that end, I note that Linux does its own git repo, and now requires
2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication

As a first step, one possibility is putting the primary repo on
bitcoin.org somewhere, and simply mirroring that to github for each
push.

-- 
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] Reconsidering github

[Dāvis Mosāns]

[-- Attachment #1: Type: text/plain, Size: 1116 bytes --]

There's actually a pretty good alternative - GitLab
<https://about.gitlab.com/> it's open source, self-hosted and provides
similar features to GitHub


2014-08-19 15:02 GMT+03:00 Jeff Garzik <jgarzik@bitpay.com>:

> 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.
>
> To that end, I note that Linux does its own git repo, and now requires
> 2FA:
> http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication
>
> As a first step, one possibility is putting the primary repo on
> bitcoin.org somewhere, and simply mirroring that to github for each
> push.
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 1990 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Wladimir]

On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay.com> 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.

Despite my complaining about github, I don't like the idea of moving
somewhere else. The current way of working - to use github for storing
the tree, and use a custom script for signing+merging - is fine with
me.

Github has a low barrier to contribution. Almost every open source
developer already has a github account. Switching to something
self-hosted makes it more difficult for people to contribute.

Plus if we have to take the hosting upon ourselves, we have to handle
sysadmin work ourselves as well. That's not a good use of the limited
manpower available.

Also it will be a lot of work to migrate over all the current issues
and pulls. I don't look forward to that. I don't see the point of
this, sorry.

Wladimir

Re: [Bitcoin-development] Reconsidering github

[Bryan Bishop]

On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> As a first step, one possibility is putting the primary repo on
> bitcoin.org somewhere, and simply mirroring that to github for each
> push.

Smaller first step would be to mirror the git repository on
bitcoin.org, which is necessary anyway before switching primaries.

- Bryan
http://heybryan.org/
1 512 203 0507

Re: [Bitcoin-development] Reconsidering github

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 802 bytes --]

-1

http://twitter.com/gubatron


On Tue, Aug 19, 2014 at 11:44 AM, Bryan Bishop <kanzure@gmail.com> wrote:

> On Tue, Aug 19, 2014 at 7:02 AM, Jeff Garzik <jgarzik@bitpay.com> wrote:
> > As a first step, one possibility is putting the primary repo on
> > bitcoin.org somewhere, and simply mirroring that to github for each
> > push.
>
> Smaller first step would be to mirror the git repository on
> bitcoin.org, which is necessary anyway before switching primaries.
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 1730 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 5:02 AM, Jeff Garzik <jgarzik@bitpay.com> 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.
>
> To that end, I note that Linux does its own git repo, and now requires
> 2FA: http://www.linux.com/news/featured-blogs/203-konstantin-ryabitsev/784544-linux-kernel-git-repositories-add-2-factor-authentication
>
> As a first step, one possibility is putting the primary repo on
> bitcoin.org somewhere, and simply mirroring that to github for each
> push.

The obvious thing to do is setup the second repository and get it
going. Git doesn't really care all that much whats "primary".  If we
have a working workflow elsewhere then making a change won't be a leap
of faith.

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

On Tue, Aug 19, 2014 at 04:58:48PM +0200, Wladimir wrote:
> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay.com> 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.
> 
> Despite my complaining about github, I don't like the idea of moving
> somewhere else. The current way of working - to use github for storing
> the tree, and use a custom script for signing+merging - is fine with
> me.
> 
> Github has a low barrier to contribution. Almost every open source
> developer already has a github account. Switching to something
> self-hosted makes it more difficult for people to contribute.
> 
> Plus if we have to take the hosting upon ourselves, we have to handle
> sysadmin work ourselves as well. That's not a good use of the limited
> manpower available.
> 
> Also it will be a lot of work to migrate over all the current issues
> and pulls. I don't look forward to that. I don't see the point of
> this, sorry.
> 
> Wladimir

If a project cannot be organized enough to run its own hosting/web presense/
counterintelligence/security that starts with installing an OS and patching
kernels, then it is really not wise for me to trust my financial future to
software written by such a group.

There is a great deal of 'work' that is really quite pointless, particularly
in regards to claims I see about security that are irrelevant unless you 
have the understanding that comes from operating and running your own 
servers. 

This includes running DDOS protection, so no cloudflare.

If bitcoin wants to become irrelevant, then by all means, continue to 
depend on github and all the unknown attack surface it exposes.

Those of us that do run our own servers will migrate to higher quality 
alternatives.

-- 
----------------------------------------------------------------------------
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

Re: [Bitcoin-development] Reconsidering github

[Gregory Maxwell]

On Tue, Aug 19, 2014 at 6:26 PM, Troy Benjegerdes <hozer@hozed.org> wrote:
> If a project cannot be organized enough to run its own hosting/web presense/
> counterintelligence/security that starts with installing an OS and patching
> kernels, then it is really not wise for me to trust my financial future to
> software written by such a group.

Please take the hyperbole elsewhere. Good dialog it's going to happen
with the insults and adhomenem.

Regardless of where the repositories live their integrity is protected
by digital signatures and cryptographic hashes. Running them elsewhere
can be virtuous for other reasons, but it doesn't play much into this
since the same tools must be used to guarantee their security.

Re: [Bitcoin-development] Reconsidering github

[Wladimir]

On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer@hozed.org> wrote:

> If bitcoin wants to become irrelevant, then by all means, continue to
> depend on github and all the unknown attack surface it exposes.
>
> Those of us that do run our own servers will migrate to higher quality
> alternatives.

So that means you're volunteering to run a web-accessible mirror of
the bitcoin repositories?

Wladimir

Re: [Bitcoin-development] Reconsidering github

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 606 bytes --]

If github were to be abandoned for anything, it'd make sense to move code
review and bug tracking elsewhere. GitHub does a reasonably good job of
hosting git repositories. It kind of sucks at code review and the issue
tracker is rudimentary at best. These days you can do "log in with my
github account" so if done well, it'd not have to be very painful.

JetBrains make great stuff and they have a code review and repository
exploration tool called Upsource in development, which should come out
soon. I think it's proprietary but that would be no different to github,
and it's designed for self hosting.

[-- Attachment #2: Type: text/html, Size: 753 bytes --]

Re: [Bitcoin-development] Reconsidering github

[xor]

[-- Attachment #1: Type: text/plain, Size: 2801 bytes --]

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



[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 4243 bytes --]

+1000. Don't fix it if it ain't broken. Don't kill community support. I for
instance wouldn't have contributed or forked if the project hadn't been on
github.

"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"

http://twitter.com/gubatron


On Fri, Aug 22, 2014 at 3:20 PM, xor <xor@freenetproject.org> 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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
>
>

[-- Attachment #2: Type: text/html, Size: 6680 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

On Wed, Aug 20, 2014 at 08:24:33AM +0200, Wladimir wrote:
> On Wed, Aug 20, 2014 at 3:26 AM, Troy Benjegerdes <hozer@hozed.org> wrote:
> 
> > If bitcoin wants to become irrelevant, then by all means, continue to
> > depend on github and all the unknown attack surface it exposes.
> >
> > Those of us that do run our own servers will migrate to higher quality
> > alternatives.
> 
> So that means you're volunteering to run a web-accessible mirror of
> the bitcoin repositories?
> 
> Wladimir

http://bitspjoule.org/hg/upstream/bitcoin

I guess I should update it more than every 6 months and then the updates
won't take so long. It would also go a lot faster if I had a couple of 
dedicated servers, but that won't happen until I sell someone a support
contract for crypto-commodities trading. I figure a bitcoin a month should
support the hardware, 24x7 monitoring, and maybe a couple of full nodes
running on the servers as well.

And to pick up from another comment on this thread if you don't understand
some of the differences between git and mercurial, or how to set up servers
that pull from git and mirror to mercurial, you will have a lot harder time
tracking down and removing malicous code that could get injected if someone
gets root on a Github server.

It is also a very usefull excercise in distributed systems design to 
understand how distributed revision control systems in theory converge to a
coherent global state, and what is similiar or different to Bitcoin's 
global consensus model of what the balance of every bitcoin address is.

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

Gerrit is free if you can afford the admin(s) to maintain it.

http://code.google.com/p/gerrit/wiki/ShowCases

And yes, I'm volunteering to get paid to be the admin, especially if you
want a 'painless' log in with a github account feature, because it will
be very painful for me to unroll the damage if github is compromised.

My preference would be that we use the same ECDSA keys we secure our
bitcoins with to secure our access to the code review and source 
control systems.

On Wed, Aug 20, 2014 at 04:16:11PM +0200, Mike Hearn wrote:
> If github were to be abandoned for anything, it'd make sense to move code
> review and bug tracking elsewhere. GitHub does a reasonably good job of
> hosting git repositories. It kind of sucks at code review and the issue
> tracker is rudimentary at best. These days you can do "log in with my
> github account" so if done well, it'd not have to be very painful.
> 
> JetBrains make great stuff and they have a code review and repository
> exploration tool called Upsource in development, which should come out
> soon. I think it's proprietary but that would be no different to github,
> and it's designed for self hosting.

-- 
----------------------------------------------------------------------------
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

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

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

Re: [Bitcoin-development] Reconsidering github

[Pieter Wuille]

On Sat, Aug 23, 2014 at 8: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:

Note that we're generally aiming (though not yet enforcing) to have
merges done through the github-merge tool, which performs the merge
locally, shows the resulting diff, compares it with the merge done by
github, and GnuPG signs it.

That allows using github as easy-access mechanism for people to
contribute and inspect, while having a higher security standard for
the actual changes done to master.

-- 
Pieter

Re: [Bitcoin-development] Reconsidering github

[Angel Leon]

[-- Attachment #1: Type: text/plain, Size: 5175 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 6649 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Drak]

[-- Attachment #1: Type: text/plain, Size: 1404 bytes --]

On 23 August 2014 12:38, Pieter Wuille <pieter.wuille@gmail.com> wrote:

> That allows using github as easy-access mechanism for people to
> contribute and inspect, while having a higher security standard for
> the actual changes done to master.


I'd also like to point out the obvious: git uses the previous hash as part
of the formula to generate the current commit hash thus tampering with
history while possible would be instantly noticed because we all have
copies of the repository. Tampering would be completely evident (pushes
would fail for a start, and even simple merges would bork). It's just not
possible to tamper with the repository without it being discovered, even
with collusion (or strong arming) of github.

The social benefits of github make it idea for open source projects that
want community participation. The barrier to entry is low. The only "weak"
spot of github is the releases section, but since we don't actually
distribute Bitcoin from github the point is moot.

I think github haters fail to see the vast benefits of a social hub like
github. Their issue tracker may not be as sophisticated, it serves well and
the project is extremely productive.

Don't shoot yourself in the foot - a move away from github would be a
disaster for the project.

When you look at the attack surface of using github, it's pretty small and
would not go unnoticed, thus nullifying concern.

[-- Attachment #2: Type: text/html, Size: 1890 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2489 bytes --]

On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote:
> 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.

Git commits serve two purposes: recording public history and
communication.  While for the purpose of recording history immutable
commits make sense, for the purpose of communicating to other developers
what changes should be added to that history you *do* want the mutable
commits that git's rebase functionality supports. Much like how
university math classes essentially never teach calculus in the order it
was developed, it is rare indeed for the way you happened to develop
some functionality to be the best sequence of changes for other
developers to understand why and what is being changed.

Anyway, just because mercurial is designed around the assumption that
commit history is immutable doesn't mean it actually is; an attacker can
fake a series of mercurial commits just as easily as they can git
commits. The only thing that protects against history rewriting is
signed commits and timestamps.


> 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.

The easiest and most useful way to achieve that would be to have a
formal program of code review, perhaps on a per-release basis, that
reviewed the diffs between the previous release and the new one. Master
repos in this scenario are simply copies of the "master master" repo
that someone has manually verified and signed-off on, with of course a
PGP signature.

If you feel like volunteering to maintain one of these repos, you may
find my Litecoin v0.8.3.7 audit report to be a useful template:

https://bitcointalk.org/index.php?topic=265582.0

-- 
'peter'[:-1]@petertodd.org
0000000000000000284b07a00c97e4770dda4dee8b45994440226435ee05ab66

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Wladimir]

>On Sat, Aug 23, 2014 at 1:38 PM, Pieter Wuille <pieter.wuille@gmail.com> >wrote:
>
> Note that we're generally aiming (though not yet enforcing) to have
> merges done through the github-merge tool, which performs the merge
> locally, shows the resulting diff, compares it with the merge done by
> github, and GnuPG signs it.

Indeed. I always use that look at and test and the merges locally
before pushing them. I never use the github merge button.

I'd recommend other people to do so as well - and as can be seen with
`git log --show-signature` it's common practice.

For browsing git history locally I find "gitk" to be a useful tool.

I'd absolutely encourage for more people to review code changes. Even
better if a few people do this through local tooling instead of the
web page. But my gut feeling is that hosting the code on github
results in many more eyes on the code overall than would be when
requiring *everyone* to use local tools. It's easy to let paranoia get
in the way of actual effectiveness.

Wladimir

Re: [Bitcoin-development] Reconsidering github

[Troy Benjegerdes]

On Sat, Aug 23, 2014 at 10:32:15AM -0400, Peter Todd wrote:
> On Sat, Aug 23, 2014 at 01:17:01AM -0500, Troy Benjegerdes wrote:
> > 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.
> 
> Git commits serve two purposes: recording public history and
> communication.  While for the purpose of recording history immutable
> commits make sense, for the purpose of communicating to other developers
> what changes should be added to that history you *do* want the mutable
> commits that git's rebase functionality supports. Much like how
> university math classes essentially never teach calculus in the order it
> was developed, it is rare indeed for the way you happened to develop
> some functionality to be the best sequence of changes for other
> developers to understand why and what is being changed.
> 
> Anyway, just because mercurial is designed around the assumption that
> commit history is immutable doesn't mean it actually is; an attacker can
> fake a series of mercurial commits just as easily as they can git
> commits. The only thing that protects against history rewriting is
> signed commits and timestamps.

What I would really like is a frontend and/or integration to Git/Mercurial that
uses Bitcoin transactions *as* the signature, which has the nice side effect of
providing timestamps backed by the full faith and credit of a billion dollar
blockchain. So what is the best way for me to stick both a git *and* a
mercurial identity hash into a bitcoin transaction?  (which leads to point 2
below)
 
> 
> > 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.
> 
> The easiest and most useful way to achieve that would be to have a
> formal program of code review, perhaps on a per-release basis, that
> reviewed the diffs between the previous release and the new one. Master
> repos in this scenario are simply copies of the "master master" repo
> that someone has manually verified and signed-off on, with of course a
> PGP signature.
> 
> If you feel like volunteering to maintain one of these repos, you may
> find my Litecoin v0.8.3.7 audit report to be a useful template:
> 
> https://bitcointalk.org/index.php?topic=265582.0

I'm not interested in volunteer, I'm interested in getting paid, and the
best way I believe I can accomplish that is use *my* bitcoin address in a
signature-transaction of the code I've reviewed.

What is the advantage of PGP? Far more people have ECDSA public-private 
keys than PGP keys.

-- 
----------------------------------------------------------------------------
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

Re: [Bitcoin-development] Reconsidering github

[Paul Rabahy]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

I want go give a bit of an outsiders perspective. I thoroughly understand
the concepts of bitcoin and am a professional programmer, but have never
taken the time to compile my own copy of bitcoin core.

I have looked at the pull requests on Github many times. I have cloned the
repo to my own computer, but haven't really used that to do much. I find
Github very easy to use, and (to me) it has the lowest bar to get more eyes
passively looking at the code. As a security guy, I appreciate the extra
time and effort that goes into signing commits and merges even if I have
not personally verified the signatures. I would like to see bitcoin core
continue to use github, but have no objection to additional mirrors of the
repo being hosted on different sites.

[-- Attachment #2: Type: text/html, Size: 814 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Gregory Maxwell]

On Sat, Aug 23, 2014 at 1:36 PM, Paul Rabahy <prabahy@gmail.com> wrote:
> I want go give a bit of an outsiders perspective. I thoroughly understand
> the concepts of bitcoin and am a professional programmer, but have never
> taken the time to compile my own copy of bitcoin core.
>
> I have looked at the pull requests on Github many times. I have cloned the
> repo to my own computer, but haven't really used that to do much. I find
> Github very easy to use, and (to me) it has the lowest bar to get more eyes
> passively looking at the code. As a security guy, I appreciate the extra
> time and effort that goes into signing commits and merges even if I have not
> personally verified the signatures. I would like to see bitcoin core
> continue to use github, but have no objection to additional mirrors of the
> repo being hosted on different sites.

Nothing suggested here would ever remove the ability to go and explore
and read the changes just as you're doing so.

Already the way it works is that our local repositories are
authoritative for each of us. (Git itself is a decentralized system
regardless of github's efforts to make it look otherwise).

Re: [Bitcoin-development] Reconsidering github

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2322 bytes --]

On Sat, Aug 23, 2014 at 12:44:14PM -0500, Troy Benjegerdes wrote:
 What I would really like is a frontend and/or integration to Git/Mercurial that
> uses Bitcoin transactions *as* the signature, which has the nice side effect of
> providing timestamps backed by the full faith and credit of a billion dollar
> blockchain. So what is the best way for me to stick both a git *and* a
> mercurial identity hash into a bitcoin transaction?  (which leads to point 2
> below)

A "bitcoin transaction" can't by itself serve as a signature, as there
isn't any way to link the transaction to what you actually care about -
a human being - without additional infrastructure. You may find it
helpful to reflect back upon your 2nd and 3rd year courses on
post-modernism and semiotics: Is a keypair in a public key cryptography
system what is being signified, or is it merely a (posssibly false)
signifier?

If you just want to timestamp a git commit you can timestamp it in the
Bitcoin blockchain. I have the code to do so in my python-bitcoinlib:

    examples/timestamp.py <git commit>

To check timestamps the following should work, although I haven't tried:

    bitcoind searchrawtransactions <git commit>

You do need the searchrawtransactions patch. I've personally timestamped
most of the git tags for releases this way.

> > If you feel like volunteering to maintain one of these repos, you may
> > find my Litecoin v0.8.3.7 audit report to be a useful template:
> > 
> > https://bitcointalk.org/index.php?topic=265582.0
> 
> I'm not interested in volunteer, I'm interested in getting paid, and the
> best way I believe I can accomplish that is use *my* bitcoin address in a
> signature-transaction of the code I've reviewed.
> 
> What is the advantage of PGP? Far more people have ECDSA public-private 
> keys than PGP keys.

PGP of course has vast amounts of identity infrastructure already
developed for it, infrastructure that simply doesn't exist for "Bitcoin
addresses"

In any case you'll be happy to know that secp256k1 has been added to the
GPG development branch, which means you can sign your code with a ECDSA
key corresponding to a Bitcoin address if you wish too.

-- 
'peter'[:-1]@petertodd.org
000000000000000006fb87cb8ec6e0981b134953f1916c513f7210b534a94b8b

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]

Re: [Bitcoin-development] Reconsidering github

[Odinn Cyberguerrilla]

> On Tue, Aug 19, 2014 at 2:02 PM, Jeff Garzik <jgarzik@bitpay.com> 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.
>
> Despite my complaining about github, I don't like the idea of moving
> somewhere else. The current way of working - to use github for storing
> the tree, and use a custom script for signing+merging - is fine with
> me.
>
> Github has a low barrier to contribution. Almost every open source
> developer already has a github account. Switching to something
> self-hosted makes it more difficult for people to contribute.
>
> Plus if we have to take the hosting upon ourselves, we have to handle
> sysadmin work ourselves as well. That's not a good use of the limited
> manpower available.
>
> Also it will be a lot of work to migrate over all the current issues
> and pulls. I don't look forward to that. I don't see the point of
> this, sorry.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

I agree with Wladimir, keep it simple.  There being many other more urgent
questions to address, imho.