From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1V1l2z-0005GI-5q for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 22:27:09 +0000 X-ACL-Warn: Received: from [162.213.26.82] (helo=zinan.dashjr.org) by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1V1l2x-0005GH-EM for bitcoin-development@lists.sourceforge.net; Tue, 23 Jul 2013 22:27:09 +0000 Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:222:4dff:fe50:4c49]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id B9F7D27A2965; Tue, 23 Jul 2013 22:27:01 +0000 (UTC) From: "Luke-Jr" To: bitcoin-development@lists.sourceforge.net Date: Tue, 23 Jul 2013 22:26:44 +0000 User-Agent: KMail/1.13.7 (Linux/3.7.10-gentoo; KDE/4.10.4; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4493899.YaHUVAZdDg"; protocol="application/pgp-signature"; micalg=pgp-sha256 Content-Transfer-Encoding: 7bit Message-Id: <201307232226.52434.luke@dashjr.org> X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 RDNS_NONE Delivered to internal network by a host with no rDNS X-Headers-End: 1V1l2x-0005GH-EM Cc: Debian Bitcoin Packaging Team Subject: Re: [Bitcoin-development] Linux packaging letter X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:27:09 -0000 --nextPart4493899.YaHUVAZdDg Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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. >=20 > 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= =20 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= =20 libraries (especially LevelDB) are bug-for-bug compatible with the ones use= d=20 by everyone else. And not only the current versions, but every future versi= on=20 to ever hit the repository. This means a lot of additional work for the=20 maintainers of the library packages, and the security team; for example, th= e=20 security team must understand that they *cannot* deploy a critical security= =20 bugfix to LevelDB until someone competent has reviewed that it is=20 behaviourally (including bug behaviours!) compatible with the versions in u= se=20 everywhere else/previously. I think it is likely all this additional=20 work/delays will be considered unacceptable to your library/security teams,= =20 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=20 Satoshi codebase, and will not be supported until someone has time to dedic= ate=20 to fixing the numerous little-endian assumptions in the code. I have an=20 incomplete port, but it isn't very high on my priority list to figure out w= hat=20 else it's missing. > 2) Bitcoin is new technology, so any patches have the ability of > harming both the network and user. >=20 > 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. >=20 > 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= =20 with no modifications, and not have any problems. It's only when you begin= =20 making modifications that it becomes a problem. There are also some concern= s=20 that it puts a much larger price on compromising Debian's build servers and= /or=20 repositories (suddenly the attacker can steal a LOT of money). The official binaries are not simply built by upstream developers: using=20 Gitian, *anyone* can produce bit-for-bit identical binaries. Official relea= ses=20 are only published after 3 or more people have done an independent compile = and=20 signed the output. It would be excellent if the whole of Debian could work= =20 toward achieving this level of security eventually, which would make=20 distributing Bitcoin node software much safer as well. Luke --nextPart4493899.YaHUVAZdDg Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) iQQcBAABCAAGBQJR7wMrAAoJEL0ClCQh9Iif0csf/2Z0bvddIgkuRHW417Um6CST sEhbrNIzHR7L2Eu5bugppCgoFew2URmHfx51Gqk5wAUV4sf63zh3XUdPyA02V3f7 2mG2guidhvAjjqulLXedKsbPZzWI/6iqfSUDwGoq0nWoGVKwO5WSvKTihmLOnIzE spXgzYk5D9ZfqOvt4Y9J+g44PZcrnsbpXeETR4Kws77ZwhKK5xDU6/fIz3n9fsaF bQkxywiB3W4D8+yrtQ1QA/kXIv8Uj27ASGXHrxuJAm5sWkftr1Z0iWqKGNxJvbaO OI5BjmoFlwTYLItAvxJwslh/j5+uRy832FGL9O8WhezmYdzg3njtcox/ZsfA4Q4p aHIG9aRAoorWfsdrbYHTwAP4HOWlizvh8djJ1efaChWSeVdDol7DHZql0xi9XS8l RgpDzfYD6sn+i76cCR3ngW/B3w0t+DCsIknCzEc22Cu6dZ826Rddc8SXZUsRF+Gj m8wSK1oBzOPkrJ5lcPwVITyPc+6D7JWFFMZ0lbv0Ki9bnOoL0YSMPIiWAt1253IS lrAQwh69kY4ffIj4sD9MHUHwAF6EgCmkQK7kiaO+OdVvgM5IPX6JoJbKt7i5cSYS RQzlHoRTO78d0pwWEqelYL8miE2ZQ3lXytZ8lgiYpx0c+9WN7gXvBIzrHU/s/3ml qP6J2Gl7FKNCgwGKjU/1qu5b5NAmBB++J1xzL3R9oNmHc1HK+El0DMts5oCt2HHZ bpwqmbpB1NfyRvocg/RqLdOX6RE8hFeAQfbWFf1nYppd2LtXyDcp8j4Vo4+IrYI6 6PiijgfSkNt7dj/n6gjkdOzpc3gERiJn4G3qZPdsVRBk46AOwGFkui8+clZY5ki6 6ZhIV66JtdFMZ2ssOaeBwsg1mbmpKsv8NQMc5AzYkF/gVrnv5CbRl5YEc4LZ7lnn 1oT4QdTV0MPKIVrbniQDd6B///jKjmwIwxjro0oGx8mZ74uE1nW6QgrorbOxHkAn 7DVhchovkcZ+4EKnAbZkY/ujCD7f8GIU5uf8aYEEse+VuQgSEV+4QcVonLpUfI9h XbZ0Uj2qJeVmJ698l8vw8KrgjANwVeZfElorLWCUbkYmcBSw2rjGVymbZHnsl+Uz yeAU2OMAsdgR06CZRkRJ2l786GhtPQSycutVscW7U3tc5f0mTWXRbPlOGdlYZ5zK SUd2u7yZcbeTCs47eSoG3lYTZCM15bhm9o6GmaR9aBOhnYo9wcm/dnoCmV7JHZye SvU40awsAvqxkYcxJUZ0xlVaDFBxSFaiHwMjSluLyAAXlL/RvCBxo4dftnidzBmN dAe0j8KUfOyBdSitZFGy6Zchw87RwukDPTFPnNQfCZWSpzz3nVisMUJ4NAi03fw= =oWeU -----END PGP SIGNATURE----- --nextPart4493899.YaHUVAZdDg--