public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Angel Leon <gubatron@gmail.com>
To: Troy Benjegerdes <hozer@hozed.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Reconsidering github
Date: Sat, 23 Aug 2014 07:59:04 -0400	[thread overview]
Message-ID: <CADZB0_ZP0XN53u4Ye+KLcOLr3zhwAxhCYCycRNZ4kcTqZ770Og@mail.gmail.com> (raw)
In-Reply-To: <20140823061701.GQ22640@nl.grid.coop>

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

  parent reply	other threads:[~2014-08-23 12:00 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 12:02 [Bitcoin-development] Reconsidering github Jeff Garzik
2014-08-19 12:28 ` Dāvis Mosāns
2014-08-19 14:58 ` Wladimir
2014-08-20  1:26   ` Troy Benjegerdes
2014-08-20  1:34     ` Gregory Maxwell
2014-08-20  6:24     ` Wladimir
2014-08-20 14:16       ` Mike Hearn
2014-08-23  5:59         ` Troy Benjegerdes
2014-08-23  5:53       ` Troy Benjegerdes
2014-08-30  3:33   ` Odinn Cyberguerrilla
2014-08-19 15:44 ` Bryan Bishop
2014-08-19 17:04   ` Angel Leon
2014-08-19 18:54 ` Gregory Maxwell
2014-08-22 19:20 ` xor
2014-08-22 19:31   ` Angel Leon
2014-08-23  6:17   ` Troy Benjegerdes
2014-08-23 11:38     ` Pieter Wuille
2014-08-23 12:05       ` Drak
2014-08-23 15:56       ` Wladimir
2014-08-23 11:59     ` Angel Leon [this message]
2014-08-23 14:32     ` Peter Todd
2014-08-23 17:44       ` Troy Benjegerdes
2014-08-23 20:36         ` Paul Rabahy
2014-08-23 20:54           ` Gregory Maxwell
2014-08-23 22:45         ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADZB0_ZP0XN53u4Ye+KLcOLr3zhwAxhCYCycRNZ4kcTqZ770Og@mail.gmail.com \
    --to=gubatron@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=hozer@hozed.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox