summaryrefslogtreecommitdiff
path: root/0d/3c50768b453413995c26bfc022eb43df5a5697
blob: 1c745ff9108aa7aa5634586174ec9f3dd655051e (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
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
228
229
230
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 49B3AD96
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 12 Jan 2018 08:54:19 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148111.authsmtp.net (outmail148111.authsmtp.net
	[62.13.148.111])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3B629D0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 12 Jan 2018 08:54:17 +0000 (UTC)
Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245])
	by punt21.authsmtp.com. (8.15.2/8.15.2) with ESMTP id w0C8sFeK023797;
	Fri, 12 Jan 2018 08:54:15 GMT (envelope-from pete@petertodd.org)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
	[52.5.185.120]) (authenticated bits=0)
	by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id w0C8sDka070840
	(version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); 
	Fri, 12 Jan 2018 08:54:14 GMT (envelope-from pete@petertodd.org)
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by petertodd.org (Postfix) with ESMTPSA id D0C7840115;
	Fri, 12 Jan 2018 08:54:12 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
	id 3E9EA20734; Fri, 12 Jan 2018 03:54:12 -0500 (EST)
Date: Fri, 12 Jan 2018 03:54:12 -0500
From: Peter Todd <pete@petertodd.org>
To: Cory Fields <lists@coryfields.com>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20180112085412.GA8088@savin.petertodd.org>
References: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/"
Content-Disposition: inline
In-Reply-To: <CAApLimjGy6TCd7kg8RKkuGqAZTfcuNSfsrDowEsEcbEnM_0rzg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 2a7b14c5-f776-11e7-9f3b-9cb654bb2504
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwAUElQaAgsB Am4bW1xeVVl7WGc7 bghPaBtcak9QXgdq
	T0pMXVMcUwUbCV91 XU8eVRl6cwUIeXt3 Z0AsXCFcDkV+JkNg
	FElTE3AHZDJndWlJ UxJFflAGdgZOLE1H b1B7GhFYa3VsNCMk
	FAgyOXU9MCtqYAJY XUknLE4ZRkcNVhU7 XR1KGDwkOnZNXCQ8 KR0gJRYfEVd5
X-Authentic-SMTP: 61633532353630.1039:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] New Bitcoin Core macOS signing key
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jan 2018 08:54:19 -0000


--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 12, 2018 at 12:04:44AM -0500, Cory Fields via bitcoin-dev wrote:
> To verify, you can use something like:
> openssl smime -verify -in sig.pkcs7 -inform pem -ignore_critical -purpose=
 any
>=20
> - "ignore_critical" setting tells openssl to ignore the Apple-specific
> critical extensions that it doesn't understand.
> - "-purpose any" allows the "purpose =3D=3D smimesign" check to be
> skipped. This would otherwise fail because this certificate is only
> authorized to sign code, not arbitrary messages.
>=20
> By now, the signature will probably fail to validate because the
> certificate has expired.

Note that you may need to add -noverify as well if your openssl doesn't have
the Apple Certificate Authority in the CA list.

While a clunky way to do it, you can use the `-signer` option to tell OpenS=
SL
to write the signer's certificate to a file. That certificate can then be
compared to the one from the repo, which was still in the repo as of the
(signed!) v0.15.1 tag.


Fun fact: OpenTimestamps has git integration, which means you can extract a=
 OTS
proof from 2016 for that certificate from the repo:

    $ git checkout v0.15.1
    $ ots git-extract share/certs/BitcoinFoundation_Apple_Cert.pem share/ce=
rts/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b823=
6775e4
    $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
    Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.p=
em'
    Success! Bitcoin attests data existed as of Thu Oct 13 14:08:59 2016 EDT

Homework problem: write a paragraph explaining how the proof generated by t=
he
above three commands are crypto snakeoil that proved little. :)

> The signed message below is timestamped on the Bitcoin blockchain
> using OpenTimestamps. See the attached ots file containing the
> timestamp proof. If the attachment gets scrubbed and doesn't make it
> to the list, don't be afraid to nag Peter Todd about a mail-friendly
> format for these proofs :)

Ha! Fortunately even the mailing list archives at lists.linuxfoundation.org
seem to contain the attachment just fine.

But anyway, I'd suggest using base64:

AE9wZW5UaW1lc3RhbXBzAABQcm9vZgC/ieLohOiSlAEITeD8FWBXd613LkHPt3JyrZBKamczrmmf
NLwSJohkYfDwEB35DezwYGb4KePty9TSWRcI//AQjTiBNRdo5I7oIeLjkGhQuAjxBFpXqSbwCN+N
8xIdwxQG/wCD3+MNLvkMji4taHR0cHM6Ly9hbGljZS5idGMuY2FsZW5kYXIub3BlbnRpbWVzdGFt
cHMub3JnCPEgijKAmyu82BuY9WL4Ags9TuzOph/XJBC6zUYZNW2Kv14I8SDyd3rD94qsLgkTPUlF
nA3SbabHilzJcHkrlGbYL+MaBgjxINCDuse4CSogHVUKQ9WaRrYkExs8PMx8O11OoVhj5ydJCPAg
y3ZstDNn/6b32WO12ZprF9zhb6VfGUl9spxU5k5eirgI8SBwa20AdPHR6oLcSdnogmPmUpWEd+n1
ky2dhWKvqZwJ/AjwIBYprQWyepSdvr1Ber0DD1eP66d4l1+138SZw7/fIflPCPAgTXOIKaeMbmNj
oO6Q/6SoX7ksCKOjkt284KYyI/ELaVgI8VkBAAAAAc1gOrgz+6mCizItuiE8bQ4foKYwCz0sB9lG
7gj/kK9fAAAAAAD9////Ag9aLAAAAAAAFgAU4gDd5F6wUprr6G4WBg+5sQkAi1YAAAAAAAAAACJq
IPAEuq8HAAgI8SAQbNEWckYQhxlLHC1aYxnyzHgxatOXQCOkQGgXe7CV7wgI8SDvEAaFSJ6unpLU
CvJzUpe2ISKMquT7kvQlvOam3SbgdggI8SBKKOTuNlh0TqP0wxy+BvCN8HgXFj/CQvJm/r9061dC
XggI8CBjdeDoADpZAb6CHjryDthP/BPcKVcMNiu+KAHIfgdDfAgI8CBuq4+F9RGpuGjFp7YU0WyH
mohtNWCv1oiDAvm6TAZeXAgI8CCI0tiLN7YMP2HtPKIm72bDi6OoFduzG0TQ1n7hEjEvvQgI8CBm
oIe62AVnwyFp6mZ37TuP0JsBHuazibGEgBKgB2xSTAgI8CDbi0srCkqentfGfk+HgBPLllDWN/mU
p4HsOQBoiDB3HwgI8SBpOitFwKhqpvNNL2SzSAxmCDIRpIpq+Kp5x774ovXexggI8SAtBMNMgP/r
L2MztJ9H43LYDRM3jGt8mbbG4Ji2+5z1rQgI8CAoVuz4NodKzCGU5c0hdBWon6T7TuMN5lA1IIOB
UF+5+QgIAAWIlg1z1xkBA7vfHvAQ5vjVlfmkli0Jsy9r6Zl5EAjxBFpXqSXwCGWEIRA/ovvQ/wCD
3+MNLvkMjiwraHR0cHM6Ly9ib2IuYnRjLmNhbGVuZGFyLm9wZW50aW1lc3RhbXBzLm9yZwjxIPEX
gnzr8J36EGTnlaF/N3bvWi0cmhlkt1b/TVIBZuCHCPEgKqjwAWBXRj1MC6oVZK6P7MBuaB5VnC+S
CpN4pfoQNJcI8CB166rXsYFaNJvQD0b6PvcK02KauHQ0G6h3dyO5NoLE1QjwIOXfM7LRnV2CFLYU
AC6uWB3K28jnM7chsxQiPXQvOmE/CPEgWmgM4iyrpd8Ip/Vs0bPeC1mdH/fgEOO+fLCR0Ae8OH0I
8CAebOJrI00jNjqWLJNxFLZaO4tY69kEKHx6AvrjoQqNzgjxWQEAAAABqY/4nDzgexnxwERsA6RG
QKS4pzagJAciBvkAbejv8mwAAAAAAP3///8CGrg4AAAAAAAWABQNuE08uA4/5oWDRYPWIW0HNrwS
ZgAAAAAAAAAAImog8AS2rwcACAjwIGQuGBXXZjCZPN527NmlDPNE7DY5jznNp8UauCoSRe3UCAjx
IPnKxEUG7HPVIm2RehYqhROpmLrZuPtr4MuMKoX+xTT1CAjwID9qxx7kHhzJrzDeZPXsvaCdQCX3
mVqkyBzlIG/Rz0TPCAjxIFHQruGgLpotZScpYu9Ou9EUmeqmizOmW77hqP04oN5/CAjwIKqKpmbK
V3weRNXWLDAWVcr0bXZndaq6th6b8dy5mjoeCAjwIA2RHHGChLN8t1f7rJJRowlLp1F3XLGD2kqK
k5M3K4c3CAjxIBwP3futX+WjxgkAS0d2TGxiyUoKMFT6bmG2o4zwmz/4CAjwIJmhwnqv64SuTiSQ
atRL1udPduUsJ6qevzrJiiuYaRuSCAjxINEU34ZeVioiqA4bBJJU8HMVlWdyYYXFnZRZ0lsKCJvc
CAjxIPjnINA1faJ/WYxuV0KSUceoHWd4EltavqltfDjTjQhcCAjwIOJixScSNRwwkg68C4HSMeRM
K5YKNh1phfaY3Du/0i68CAgABYiWDXPXGQEDt98e

On Linux, the `base64 -d` command will decode the above just fine.

The _real_ issue is that asking the user to cut-n-paste that PKCS7-encoded
message is problematic, as differences in whitespace and line endings will =
make
the verification fail. Works fine on Linux, but would probably have failed =
on
Windows.

What's nice about OpenPGP's "clearsigned" format is how it ignores whitespa=
ce;
a replica of that might be a nice thing for OTS to be able to do too. Though
that's on low priority, as there's some tricky design choices(1) to be made=
 about
how to nicely nest clearsigned PGP within OTS.


1) For example, I recently found a security hole related to clearsigned PGP
recently. Basically the issue was that gpg --verify will return true on a f=
ile
that looks like the following:

    1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a  foo-v=
2.0.tar.gz
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  foo-v=
1.0.tar.gz
    -----BEGIN PGP SIGNATURE-----

    <snip pgp stuff>
    -----END PGP SIGNATURE-----

The system I was auditing then did something like this to verify that the f=
ile
was signed:

    set -e # exit immediately on error
    gpg --verify SHA256SUMS.asc
    cat SHA256SUMS.asc | grep foo-v2.0.tar.gz
    <do installation>

While it makes it a bit less user friendly, the fact that PKCS7's encoding =
made
it impossible to see the message you signed until it's been properly verifi=
ed
is a good thing re: security.

And yes, I checked: Bitcoin Core's contrib/verifybinaries/verify.sh isn't
vulnerable to this mistake. :)

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCAAGBQJaWHevAAoJECSBQD2l8JH7FeUH/3BzbohIGMCz0Gr/wZpoz3qr
3eO4SMer15N19p2Y4M7tK6D2S+kknk9AwpdG79o/pmaSEb8cwhtMGtKqYLgmQZ5Q
Gcnzpugyo0VQP+xlLPCD/Us6MpGJrY6LYQxEooR3GNfAypr8DkFRxLaO+tu+tuI/
BjfX7wJez1tYD24hgQJJenUSOdpnm1P/bBkGSJpDT4Yigo7aFLVmuPyGA9l3c/4H
twtJTx9+PnahwbBTBPwQJsaRsL5ACUSjLwWVWK7I4nM3BMsvHtWUWDOHXG1EUOj9
nCN455/MQ+WHlCTfPHjWmUs4fBqBj9LUoD4BP0sZ7+d0MoN7mmzhaQf8Cwj2uSg=
=0GbP
-----END PGP SIGNATURE-----

--TB36FDmn/VVEgNH/--