On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr <l...@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 ------------------------------------------------------------------------------ See everything from the browser to the database with AppDynamics Get end-to-end visibility with application monitoring from AppDynamics Isolate bottlenecks and diagnose root cause in seconds. Start your free trial of AppDynamics Pro today! http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
