From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 49B3AD96 for ; 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 ; 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 To: Cory Fields , Bitcoin Protocol Discussion Message-ID: <20180112085412.GA8088@savin.petertodd.org> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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----- -----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 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/--