summaryrefslogtreecommitdiff
path: root/d2/a8e0d6e1e339fbc053e405ab6f51463d47b862
blob: 1e767b55a209ed33cdb9c082397ad6503d32abcf (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
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 <luke@dashjr.org>) 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" <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>
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 <pkg-bitcoin-devel@lists.alioth.debian.org>
Subject: Re: [Bitcoin-development] Linux packaging letter
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=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--