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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <showard314@gmail.com>) id 1V1pJj-0002gv-1Z
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Jul 2013 03:00:43 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.192.173 as permitted sender)
client-ip=209.85.192.173; envelope-from=showard314@gmail.com;
helo=mail-pd0-f173.google.com;
Received: from mail-pd0-f173.google.com ([209.85.192.173])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1V1pJi-0002m4-48
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Jul 2013 03:00:43 +0000
Received: by mail-pd0-f173.google.com with SMTP id bv13so1572277pdb.32
for <bitcoin-development@lists.sourceforge.net>;
Tue, 23 Jul 2013 20:00:36 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.68.131.68 with SMTP id ok4mr40102347pbb.146.1374634836218;
Tue, 23 Jul 2013 20:00:36 -0700 (PDT)
Received: by 10.70.15.66 with HTTP; Tue, 23 Jul 2013 20:00:36 -0700 (PDT)
In-Reply-To: <201307232226.52434.luke@dashjr.org>
References: <CANEZrP2GvgZP_1z3EoSs3p+db7tZB6JfEVAewLpGE5eRpGgR3w@mail.gmail.com>
<CANg8-dAzc2ENivTpr6S=zoUkfGyBM6j=OUb8-_wLTFQqLRmnzw@mail.gmail.com>
<201307232226.52434.luke@dashjr.org>
Date: Tue, 23 Jul 2013 23:00:36 -0400
Message-ID: <CANg8-dBfcOBKGtkw8DGn-VJDbUyv0bbwK2Nm7CBo3tZrQ_5Zwg@mail.gmail.com>
From: Scott Howard <showard314@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Spam-Score: -1.4 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [209.85.192.173 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(showard314[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (showard314[at]gmail.com)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1V1pJi-0002m4-48
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>,
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: Wed, 24 Jul 2013 03:00:43 -0000
On Tue, Jul 23, 2013 at 6:26 PM, Luke-Jr <luke@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
|
