From: Scott Howard <showard314@gmail•com>
To: Luke-Jr <luke@dashjr•org>
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
Date: Tue, 23 Jul 2013 23:00:36 -0400 [thread overview]
Message-ID: <CANg8-dBfcOBKGtkw8DGn-VJDbUyv0bbwK2Nm7CBo3tZrQ_5Zwg@mail.gmail.com> (raw)
In-Reply-To: <201307232226.52434.luke@dashjr.org>
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
next prev parent reply other threads:[~2013-07-24 3:00 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
2013-07-24 3:00 ` Scott Howard [this message]
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=CANg8-dBfcOBKGtkw8DGn-VJDbUyv0bbwK2Nm7CBo3tZrQ_5Zwg@mail.gmail.com \
--to=showard314@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=luke@dashjr$(echo .)org \
--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