[bitcoin-dev] New Bitcoin Core macOS signing key

Fri Jan 12 08:54:12 UTC 2018

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
> 
> - "ignore_critical" setting tells openssl to ignore the Apple-specific
> critical extensions that it doesn't understand.
> - "-purpose any" allows the "purpose == smimesign" check to be
> skipped. This would otherwise fail because this certificate is only
> authorized to sign code, not arbitrary messages.
> 
> 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 OpenSSL
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/certs/BitcoinFoundation_Apple_Cert.pem.ots 36f60a5d5b1bc9a12b87d6475e3245b8236775e4
    $ ots verify share/certs/BitcoinFoundation_Apple_Cert.pem.ots
    Assuming target filename is 'share/certs/BitcoinFoundation_Apple_Cert.pem'
    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 the
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 whitespace;
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 file
that looks like the following:

    1d7a363ce12430881ec56c9cf1409c49c491043618e598c356e2959040872f5a  foo-v2.0.tar.gz
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA256

    e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855  foo-v1.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 file
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 verified
is a good thing re: security.

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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180112/bfd7c512/attachment.sig>