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 --]
next prev parent 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 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$(echo .)org \
--cc=arto@bendiken$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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