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
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
|
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 <mh.in.england@gmail.com>) id 1UNgCa-0007W8-2Z
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Apr 2013 09:11:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.172 as permitted sender)
client-ip=209.85.214.172; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f172.google.com;
Received: from mail-ob0-f172.google.com ([209.85.214.172])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1UNgCY-0005HZ-A2
for bitcoin-development@lists.sourceforge.net;
Thu, 04 Apr 2013 09:11:24 +0000
Received: by mail-ob0-f172.google.com with SMTP id tb18so2315371obb.17
for <bitcoin-development@lists.sourceforge.net>;
Thu, 04 Apr 2013 02:11:15 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.182.151.9 with SMTP id um9mr3430376obb.89.1365066675602;
Thu, 04 Apr 2013 02:11:15 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.162.198 with HTTP; Thu, 4 Apr 2013 02:11:15 -0700 (PDT)
In-Reply-To: <CAD2Ti28bdeGnhVe-i5-R54q6D082BVFjxVLCgvsSAjA+LQx2MA@mail.gmail.com>
References: <CAKaEYhK5ZzP8scbhyzkEU+WdWjwMBDzkgF+SrC-Mdjgo9G9RnA@mail.gmail.com>
<CACezXZ94oDX1O7y7cgh+HvDj4QiDWmy1NVQ4Ahq=gmzhgmUaHQ@mail.gmail.com>
<CAKaEYhK4v3mhkGMKDW9g7km+5artBAjpukQdwx17psgdJaqvgA@mail.gmail.com>
<CAHQs=o4pKBoVO-14dqoq9EoNxq2BNnKE+zmOjLBw+XqJfAp8yA@mail.gmail.com>
<CAKaEYh+bePsmzM5XU1wpb_SFrTnbKB8LxMvWLLqP4p8KuesuSA@mail.gmail.com>
<20130401225107.GU65880@giles.gnomon.org.uk>
<20130401225417.GV65880@giles.gnomon.org.uk>
<CA+s+GJBLUTfu8q2zE4pJ+HO5u-GweGNKZebV=XRhBe7TCPggPg@mail.gmail.com>
<CA+8xBpcZtsZ=p30hJtqLTBJPEE3eD=gQ+x6bKy46z0hc8XNB1Q@mail.gmail.com>
<CAD2Ti2-quRpfARLHw3riFpFihwYy2+R+4AW7Ovxq-W3qkzKptw@mail.gmail.com>
<CABsx9T1EmYer-85zrEdC-N0uS_nnuGVgz0QcZ+ROrn51uPSNLQ@mail.gmail.com>
<CAD2Ti2_54CfHS8oy=b3VQTqZMighmjfiaYFEqMB+Xou8Uamr9w@mail.gmail.com>
<CAAS2fgT06RHBO_0stKQAYLPB39ZAzaCVduFZJROjSzXUP4Db+g@mail.gmail.com>
<CAD2Ti28bdeGnhVe-i5-R54q6D082BVFjxVLCgvsSAjA+LQx2MA@mail.gmail.com>
Date: Thu, 4 Apr 2013 10:11:15 +0100
X-Google-Sender-Auth: 9SG0Og0cCEGnad5AXPyStwOxh84
Message-ID: <CANEZrP2TNb8AjJzO78cdTX72vSVYR06xRR8QN5Lru_u0g_JawA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: grarpamp <grarpamp@gmail.com>
Content-Type: multipart/alternative; boundary=f46d0444e9254b4b6f04d9855a8b
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1UNgCY-0005HZ-A2
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] bitcoin pull requests
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: Thu, 04 Apr 2013 09:11:24 -0000
--f46d0444e9254b4b6f04d9855a8b
Content-Type: text/plain; charset=UTF-8
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at 7:12 PM, grarpamp <grarpamp@gmail.com> wrote:
> > Users will have available multisig addresses which require
> > transactions to be signed off by a wallet HSM. (E.g. a keyfob
>
> Hardware is a good thing. But only if you do the crypto in the
> hardware and trust the hardware and its attack models ;) For
> instance, the fingerprint readers you see everywhere... many
> of them just present the raw fingerprint scan to the host (and
> host software), instead of hashing the fingerprint internally and
> using that as primitive in crypto exchanges with the host. They
> cheaped out and/or didn't think. So oops, there went both your
> security (host replay) and your personal privacy (biometrics),
> outside of your control. All with no protection against physical
> fingerprint lifting.
>
> > This doesn't remove the need to improve repository integrity. ... but
> > repository integrity is a general problem that is applicable to many
> > things (after all, what does it matter if you can't compromise Bitcoin
> > if you can compromise boost, openssl, or gcc?)
>
> Yes, that case would matter zero to the end product. However
> having a strong repo permits better auditing of the BTC codebase.
> That's a good thing, and eliminates the need to talk chicken and
> egg.
>
> > It's probably best
> > that Bitcoin specalists stay focused on Bitcoin security measures, and
> > other people interested in repository security come and help out
> > improving it. An obvious area of improvement might be oddity
> > detection and alerting: It's weird that I can rewrite history on
> > github, so long as I do it quickly, without anyone noticing.
>
> If no one is verifying the repo, sure, even entire repos could be
> swapped out for seemingly identical ones.
>
> Many repos do not have any strong internal verification structures
> at all, and they run on filesystems that accept bitrot.
> Take a look at some OS's... OpenBSD and FreeBSD, supposedly
> the more secure ones out there... both use legacy repos on FFS.
> Seems rather ironic in the lol department.
>
> Thankfully some people out there are finally getting a clue on these
> issues, making and learning the tools, converting and migrating
> things, working on top down signed build and distribution chain, etc...
> so maybe in ten years the opensource world will be much farther
> ahead. Or at least have a strong audit trail.
>
>
> ------------------------------------------------------------------------------
> Minimize network downtime and maximize team effectiveness.
> Reduce network management and security costs.Learn how to hire
> the most talented Cisco Certified professionals. Visit the
> Employer Resources Portal
> http://www.cisco.com/web/learning/employer_resources/index.html
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d0444e9254b4b6f04d9855a8b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">My general hope/vague plan for bitcoinj based wallets is t=
o get them all on to automatic updates with threshold signatures. Combined =
with regular audits of the initial downloads for new users, that should giv=
e a pretty safe result that is immune to a developer going rogue.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed, Apr 3=
, 2013 at 7:12 PM, grarpamp <span dir=3D"ltr"><<a href=3D"mailto:grarpam=
p@gmail.com" target=3D"_blank">grarpamp@gmail.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
> Users will have available multisig addresses which require<br>
> transactions to be signed off by a wallet HSM. (E.g. a keyfob<br>
<br>
Hardware is a good thing. But only if you do the crypto in the<br>
hardware and trust the hardware and its attack models ;) For<br>
instance, the fingerprint readers you see everywhere... many<br>
of them just present the raw fingerprint scan to the host (and<br>
host software), instead of hashing the fingerprint internally and<br>
using that as primitive in crypto exchanges with the host. They<br>
cheaped out and/or didn't think. So oops, there went both your<br>
security (host replay) and your personal privacy (biometrics),<br>
outside of your control. All with no protection against physical<br>
fingerprint lifting.<br>
<br>
> This doesn't remove the need to improve repository integrity. ... =
but<br>
> repository integrity is a general problem that is applicable to many<b=
r>
> things (after all, what does it matter if you can't compromise Bit=
coin<br>
> if you can compromise boost, openssl, or gcc?)<br>
<br>
Yes, that case would matter zero to the end product. However<br>
having a strong repo permits better auditing of the BTC codebase.<br>
That's a good thing, and eliminates the need to talk chicken and<br>
egg.<br>
<br>
> It's probably best<br>
> that Bitcoin specalists stay focused on Bitcoin security measures, and=
<br>
> other people interested in repository security come and help out<br>
> improving it. =C2=A0An obvious area of improvement might be oddity<br>
> detection and alerting: =C2=A0It's weird that I can rewrite histor=
y on<br>
> github, so long as I do it quickly, without anyone noticing.<br>
<br>
If no one is verifying the repo, sure, even entire repos could be<br>
swapped out for seemingly identical ones.<br>
<br>
Many repos do not have any strong internal verification structures<br>
at all, and they run on filesystems that accept bitrot.<br>
Take a look at some OS's... OpenBSD and FreeBSD, supposedly<br>
the more secure ones out there... both use legacy repos on FFS.<br>
Seems rather ironic in the lol department.<br>
<br>
Thankfully some people out there are finally getting a clue on these<br>
issues, making and learning the tools, converting and migrating<br>
things, working on top down signed build and distribution chain, etc...<br>
so maybe in ten years the opensource world will be much farther<br>
ahead. Or at least have a strong audit trail.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Minimize network downtime and maximize team effectiveness.<br>
Reduce network management and security costs.Learn how to hire<br>
the most talented Cisco Certified professionals. Visit the<br>
Employer Resources Portal<br>
<a href=3D"http://www.cisco.com/web/learning/employer_resources/index.html"=
target=3D"_blank">http://www.cisco.com/web/learning/employer_resources/ind=
ex.html</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--f46d0444e9254b4b6f04d9855a8b--
|
