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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1YGUlU-0006Wz-Cg
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 15:42:48 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YGUlT-00055l-6f
for bitcoin-development@lists.sourceforge.net;
Wed, 28 Jan 2015 15:42:48 +0000
Received: by mail-wi0-f177.google.com with SMTP id r20so12781887wiv.4
for <bitcoin-development@lists.sourceforge.net>;
Wed, 28 Jan 2015 07:42:42 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.37.77 with SMTP id w13mr8390391wij.66.1422459762153;
Wed, 28 Jan 2015 07:42:42 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.194.188.9 with HTTP; Wed, 28 Jan 2015 07:42:42 -0800 (PST)
In-Reply-To: <CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
References: <CALYO6Xt-jTYwpywUaH-s4YPYyGUp1_BLSEswscnwX+Vu166Lcw@mail.gmail.com>
<alpine.DEB.2.10.1501281419110.21680@nzrgulfg.ivfhpber.pbz>
<CALYO6Xv=k+Ztvke90SDB91StFBL7C0U49ufMD-WjG91uHLshFg@mail.gmail.com>
Date: Wed, 28 Jan 2015 16:42:42 +0100
X-Google-Sender-Auth: V0oaR9lRiFFbyTE2CXReRQNQ0Uk
Message-ID: <CANEZrP3PCHaTO3-HA3GHFxwuJJpW2dbvPuV4R1sFPcFW49uGgw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Nicolas DORIER <nicolas.dorier@gmail.com>
Content-Type: multipart/alternative; boundary=e89a8f647021d49ffa050db8382b
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: 1YGUlT-00055l-6f
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for
encoding?
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, 28 Jan 2015 15:42:48 -0000
--e89a8f647021d49ffa050db8382b
Content-Type: text/plain; charset=UTF-8
>
> On the other hand, if you charge the developer (and not the plateform) to
> check certificate validity, it means that you have to develop a different
> codebase for all plateform you are targeting, because each plateform store
> trusted root certificate in a different manner with different APIs, and
> also have different types representing a X509 Certificate.
>
That's what cross-platform abstraction libraries are for. Both Java and Qt
provide a key store library that can load from either the OS root store or
a custom one. If your chosen app platform doesn't, OK, then you'll have to
make or find one yourself. Perhaps contribute it upstream or make it a
library. But that's not a limitation of BIP70.
Just as a reminder, there is no obligation to use the OS root store. You
can (and quite possibly should) take a snapshot of the Mozilla/Apple/MSFT
etc stores and load it in your app. We do this in bitcoinj by default to
avoid cases where BIP70 requests work on some platforms and not others,
although the developer can easily override this and use the OS root store
instead.
Of all possible solutions, using a third party service to convert things to
JSON is one of the least obvious and highest effort. I don't know anyone
else who arrived at such a conclusion and respectfully disagree that this
is a problem with the design choices in BIP70. It sounds like a bizarre
hack around lack of features in whatever runtime you're using.
--e89a8f647021d49ffa050db8382b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div dir=3D"ltr"><div><div>On the other hand, if=
you charge the
developer (and not the plateform) to check certificate validity, it=20
means that you have to develop a different codebase for all plateform=20
you are targeting, because each plateform store trusted root certificate
in a different manner with different APIs, and also have different=20
types representing a X509 Certificate.<br></div></div></div></blockquote><d=
iv><br></div><div>That's what cross-platform abstraction libraries are =
for. Both Java and Qt provide a key store library that can load from either=
the OS root store or a custom one. If your chosen app platform doesn't=
, OK, then you'll have to make or find one yourself. Perhaps contribute=
it upstream or make it a library. But that's not a limitation of BIP70=
.</div><div><br></div><div>Just as a reminder, there is no obligation to us=
e the OS root store. You can (and quite possibly should) take a snapshot of=
the Mozilla/Apple/MSFT etc stores and load it in your app. We do this in b=
itcoinj by default to avoid cases where BIP70 requests work on some platfor=
ms and not others, although the developer can easily override this and use =
the OS root store instead.</div><div>=C2=A0</div><div>Of all possible solut=
ions, using a third party service to convert things to JSON is one of the l=
east obvious and highest effort. I don't know anyone else who arrived a=
t such a conclusion and respectfully disagree that this is a problem with t=
he design choices in BIP70. It sounds like a bizarre hack around lack of fe=
atures in whatever runtime you're using.</div><div><br></div></div></di=
v></div>
--e89a8f647021d49ffa050db8382b--
|
