Luke-Jr [ARCHIVE] on Nostr: 📅 Original date posted:2013-07-23 📝 Original message:On Tuesday, July 23, 2013 ...
📅 Original date posted:2013-07-23
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1530 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/583a77e0/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1530 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130723/583a77e0/attachment.sig>;