public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Arto Bendiken <arto@bendiken.net>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Code review
Date: Fri, 4 Oct 2013 08:14:15 -0400	[thread overview]
Message-ID: <20131004121415.GA7084@savin> (raw)
In-Reply-To: <CAE7aNuS00t97g8K-sPJv4Xt+zWbWbDEjfkza8oBq4c5RjfRP1Q@mail.gmail.com>

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

On Fri, Oct 04, 2013 at 01:58:51PM +0200, Arto Bendiken wrote:
> On Fri, Oct 4, 2013 at 1:35 PM, Peter Todd <pete@petertodd.org> wrote:
> > The second caveat is more specific to Bitcoin: people tend to rebase
> > their pull-requests over and over again until they are accepted, but
> > that also means that code review done earlier doesn't apply to the later
> > code pushed. Bitcoin is a particularly high profile, and high profit,
> > target for people trying to get malicious code into the codebase.
> 
> On that note, this 2003 example of an attempt to backdoor the Linux
> kernel is pertinent:
> 
> http://lwn.net/Articles/57135/
> 
> The backdoor in question came down to a single missing character,
> easily overlooked by a reviewer if a spotlight hadn't been thrown on
> it for other reasons. Compromising a Bitcoin implementation isn't
> going to be as easy as that, one would hope, but certainly it seems
> only a matter of time until there's an attempt at it.

Exactly.

Ideally code review discussions would be PGP signed and have a mechanism
for someone to sign a commit saying they had in fact reviewed it.
Combined with git's per-commit signature mechanism it'd make it possible
to write a git-pull hook that checked that whatever was being pulled had
some sufficient number of signatures from people whose reviews you
trusted. With such a system you could host code review anywhere safely,
or for that matter, use a completely distributed system.

But that's going to be a long way off. In the meantime github is
probably more trustworthy and competent than anything we ran ourselves,
and we should focus on making sure reviewers eyeballs actually look at
the code that ends up in master.

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

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

  reply	other threads:[~2013-10-04 12:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-04 10:30 [Bitcoin-development] Code review Mike Hearn
2013-10-04 10:42 ` Andy Parkins
2013-10-04 11:32   ` Mike Hearn
2013-10-04 12:34     ` Andy Parkins
2013-10-04 11:35   ` Peter Todd
2013-10-04 11:58     ` Arto Bendiken
2013-10-04 12:14       ` Peter Todd [this message]
2013-10-04 12:34     ` Andy Parkins
2013-10-04 11:53 ` Peter Todd
2013-10-04 12:14   ` Mike Hearn
2013-10-04 12:22     ` Eugen Leitl
2013-10-05  2:31 ` Gavin Andresen
2013-10-05  4:02   ` Warren Togami Jr.
2013-10-05 11:36   ` Mike Hearn

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=20131004121415.GA7084@savin \
    --to=pete@petertodd.org \
    --cc=arto@bendiken.net \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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