public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd•org>
To: Troy Benjegerdes <hozer@hozed•org>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Reconsidering github
Date: Sat, 23 Aug 2014 10:32:15 -0400	[thread overview]
Message-ID: <20140823143215.GA18452@savin.petertodd.org> (raw)
In-Reply-To: <20140823061701.GQ22640@nl.grid.coop>

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

  parent reply	other threads:[~2014-08-23 14:34 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-19 12:02 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
2014-08-23 14:32     ` Peter Todd [this message]
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=20140823143215.GA18452@savin.petertodd.org \
    --to=pete@petertodd$(echo .)org \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=hozer@hozed$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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