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