Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.192.173 as permitted sender)
	client-ip=209.85.192.173; envelope-from=showard314@gmail.com;
	helo=mail-pd0-f173.google.com; 
MIME-Version: 1.0
In-Reply-To: <201307232226.52434.luke@dashjr.org>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
	<CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
	<201307232226.52434.luke@dashjr.org>
Date: Tue, 23 Jul 2013 23:00:36 -0400
Message-ID: <CANg8-dBfcOBKGtkw8DGn-VJDbUyv0bbwK2Nm7CBo3tZrQ_5Zwg@mail.gmail.com>
From: Scott Howard <showard314@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
	Debian Bitcoin Packaging Team <pkg-bitcoin-devel@lists.alioth.debian.org>
Subject: Re: [Bitcoin-development] Linux packaging letter
Precedence: list

On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr <luke@dashjr.org> wrote:
> 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.

The above is a key point, lukejr addressed it well "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.

To be clear, bitcoind/bitcoin-qt is only built on little endian machines
https://buildd.debian.org/status/package.php?p=bitcoin

> 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 only current modification is to use system leveldb instead of the
packaged leveldb. (There is also a patch porting libmemenv.a to
several other architectures, but that is only used in test suites - so
it shouldn't pose a risk to users).

>
> 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.

Ironically, debian (in general) doesn't trust upstream security
maintenance of third part libraries - that's why they typically get
dropped in favor of use system libraries.

In this case, upstream doesn't trust (rightfully) that some future
debian security team bug fix to a stable library won't be tested
properly against bitcoin, causing problems for users (since bitcoin
might expect buggy library behavior).


I'm not the original packager or maintainer - I just came across the
package in really bad shape and helped bring it to something
reasonable and have done the most recent uploads (since 0.8, I
believe). Since updated libraries could pose a security risk because
bitcoin may expect buggy behavior, I think that is a good argument for
debian to use the included library. However, I'm just a recent helper
- I still want to hear what people who have been doing this for longer
think.

~Scott