Angel Leon [ARCHIVE] on Nostr: đ Original date posted:2014-08-23 đ Original message:I think this is the only ...
đ
Original date posted:2014-08-23
đ Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/03d92c0a/attachment.html>;
đ Original message: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 at 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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140823/03d92c0a/attachment.html>;