On Tue, Jul 22, 2014 at 17:17, Peer Janssen wrote: > I'm trying to establish a clean and uninterrupted trail of trust > (integrity-wise) from Alice the OpenBSD devs to the OpenBSD 5.5 CD set I > recently bought in a bookshop in a big german city. This proves > surprisingly difficult.
hmmm. traditionally, the CDs have been the way one verifies OpenBSD, not the other way around. you can compare the files on the CD, of course, but the CD available for purchase is made a little bit independently of the actual OpenBSD release that you would find on the ftp/http mirrors. > The OpenBSD 5.5 web page provides a build key (no idea what kind of > format it's in) and the web site strongly recommends checking the CD > beforehand (just what I'm trying to do) using the signify tool, but > since I have to somehow bootstap OpenBSD, I didn't have that tool nor > any other means of verification, e.g. a md5sum, sha256sum or so of the > CD is not provided on the website (that would have helped the > bootstrapping process). (With hindsight, I could have manually scripted > some SHA check for the OpenBSD hash file format.) Yes, bootstrapping is a hard problem. The current solution is "once everybody has OpenBSD installed, they will be able to verify their upgrades." > One file named "SHA" verified "FAILED" because the file listed and > hashed in the SHA256.sig of the checked directory is missing on the CD. > So now there is some rest of a doubt if the CD is legit or not or if > this is a just a minor production error. There aren't supposed to be any files named SHA (as opposed to SHA256) anywhere, but that could be an artifact of production. It's pretty difficult to create CDs that both contain signatures and are themselves signed.
