From: "Luke-Jr" <luke@dashjr.org>
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: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
	<CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
In-Reply-To: <CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
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>
Cc: Debian Bitcoin Packaging Team <pkg-bitcoin-devel@lists.alioth.debian.org>
Subject: Re: [Bitcoin-development] Linux packaging letter
Precedence: list

--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--