Re: [Bitcoin-development] Linux packaging letter

["Luke-Jr" <luke@dashjr.org>]

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