public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Luke-Jr" <luke@dashjr.org>
To: bitcoin-development@lists.sourceforge.net
Cc: Debian Bitcoin Packaging Team
	<pkg-bitcoin-devel@lists.alioth.debian.org>
Subject: Re: [Bitcoin-development] Linux packaging letter
Date: Tue, 23 Jul 2013 22:26:44 +0000	[thread overview]
Message-ID: <201307232226.52434.luke@dashjr.org> (raw)
In-Reply-To: <CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>

[-- Attachment #1: Type: Text/Plain, Size: 3667 bytes --]

On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote:
> 1) It appears that the consensus of upstream developers is that any
> distributed binary should only be linked against libraries that the
> bitcoin developers have tested and audited since any compatibility bug
> is a risk to both the user and the network.
> 
> Response: Is there a way to "certify" the Debian libraries? Debian
> bitcoind/bitcoin-qt runs the compile test during all architectures.

It doesn't need to be audited by any given person or team, just someone who 
understands the issues and can dedicate the time to doing a competent audit.
Testing bitcoind/bitcoin-qt is not sufficient: you must guarantee that your 
libraries (especially LevelDB) are bug-for-bug compatible with the ones used 
by everyone else. And not only the current versions, but every future version 
to ever hit the repository. This means a lot of additional work for the 
maintainers of the library packages, and the security team; for example, the 
security team must understand that they *cannot* deploy a critical security 
bugfix to LevelDB until someone competent has reviewed that it is 
behaviourally (including bug behaviours!) compatible with the versions in use 
everywhere else/previously. I think it is likely all this additional 
work/delays will be considered unacceptable to your library/security teams, 
thus using the bundled/embedded LevelDB is probably the best solution.

> MIPS has been failing recently, but no one has looked into it yet.
> Perhaps it's not worth developers efforts yet, but at some point the
> technology should reach a point it can be redistributed.

MIPS (and any other big endian architecture) has *always* failed on the 
Satoshi codebase, and will not be supported until someone has time to dedicate 
to fixing the numerous little-endian assumptions in the code. I have an 
incomplete port, but it isn't very high on my priority list to figure out what 
else it's missing.

> 2) Bitcoin is new technology, so any patches have the ability of
> harming both the network and user.
> 
> Response: I, and I'm sure everyone else working on it, totally agrees.
> All patches are public [1], you can see that the patches are only to
> the build system (except for one adding a debug message). Is there a
> specific patch or bug that is problematic? This seems to be
> reiterating (1) above: don't patch the build system to use libraries
> that were not audited by the developers.
> 
> The two solutions are: (1) no one besides the upstream developers
> compiles and distributes binaries, ever, or (2) upstream comes up with
> a system where someone besides them can compile working binaries for
> distribution. Most likely the best solution is to do (1) until
> upstream sets up a system to allow (2).

Debian could probably get away with packaging Bitcoin-Qt and bitcoind as-is 
with no modifications, and not have any problems. It's only when you begin 
making modifications that it becomes a problem. There are also some concerns 
that it puts a much larger price on compromising Debian's build servers and/or 
repositories (suddenly the attacker can steal a LOT of money).

The official binaries are not simply built by upstream developers: using 
Gitian, *anyone* can produce bit-for-bit identical binaries. Official releases 
are only published after 3 or more people have done an independent compile and 
signed the output. It would be excellent if the whole of Debian could work 
toward achieving this level of security eventually, which would make 
distributing Bitcoin node software much safer as well.

Luke

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 1530 bytes --]

  reply	other threads:[~2013-07-23 22:27 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-23 20:01 [Bitcoin-development] Linux packaging letter Mike Hearn
2013-07-23 20:14 ` Gregory Maxwell
2013-07-23 20:32   ` Mike Hearn
2013-07-23 20:50     ` Gregory Maxwell
2013-07-28 18:21       ` John Dillon
2013-07-23 22:02 ` Scott Howard
2013-07-23 22:26   ` Luke-Jr [this message]
2013-07-24  3:00     ` Scott Howard
2013-07-24  1:45   ` Douglas Huff
2013-07-24  2:27     ` Scott Howard
2013-07-24  3:54     ` [Bitcoin-development] Endianness (was: Linux packaging letter) Wendell
2013-07-24  4:03       ` Luke-Jr
2013-07-24  4:07       ` Gregory Maxwell
2013-07-24  4:09         ` Gregory Maxwell
2013-07-23 22:33 ` [Bitcoin-development] Linux packaging letter Pieter Wuille
2013-07-23 23:23 ` Greg Troxel
2013-07-23 23:45   ` Luke-Jr
2013-07-24  0:50   ` Gregory Maxwell
2013-07-24  2:35     ` zooko
2013-07-24  3:19       ` Gregory Maxwell
2013-07-24  8:28         ` Mike Hearn
2013-07-24 13:52           ` Jeff Garzik
2013-07-24 15:32             ` zooko
2013-07-24 19:35               ` Gregory Maxwell
2013-07-24 16:01           ` zooko
2013-07-27  0:45           ` Greg Troxel
2013-07-27  0:43     ` Greg Troxel

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=201307232226.52434.luke@dashjr.org \
    --to=luke@dashjr.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pkg-bitcoin-devel@lists.alioth.debian.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