On Wed, Feb 21, 2018 at 4:10 AM, Jean-Michel Pouré <[email protected]> wrote: > I know this is a little bit farfetched, pardon my ignorence, but > OpenBSD seeems vulnerable on first installation. In case of DNS > poisoning, what can stop a virus from forwarding the installer to a > false SHA256.sig and false repository? My guess would be to use > DNSSEC and a local copy of an OpenBSD repository to avoid such issue. > > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it?
This is not farfetched at all. If you obtain the ISO from an untrustworthy source, or you are misdirected to a false repository, then you cannot trust the ISO you receive. Likewise, you cannot trust any SHA256.sig file you receive. So, after you download SHA256.sig, you need a way to confirm that your copy of SHA256.sig is genuine, then once that's done you can verify whether your ISO is valid. This is what the signify tool does. It is small enough that you should be able to build it yourself on a machine you trust, and the OpenBSD pubkey that you need for SHA256.sig verification is small enough that you can key it in by hand if needed, and also small enough that you can visually confirm you have the correct key by comparing it with one from a trusted source (an original OpenBSD CD-ROM, a T-shirt, a picture you took during an OpenBSD presentation, etc.) The SHA256.sig that already exists can't be included in the ISO because it contains the signature of the ISO itself. So imagine you've made an ISO image, then you get the SHA256 hash of it, make and sign a SHA256.sig file`, but then you need to take this new file you've just created and put it into the ISO, which will cause the ISO's hash to change, invalidating the SHA256.sig you just created. So you would need to have two versions of SHA256.sig, one version that contains hashes for the ISO file (and also other 'installer' files like miniroot.fs and installNN.fs), and another SHA256.sig that contains hashes for the base sets (baseNN.tgz, compNN.tgz, gamesNN.tgz, etc.) and you would put the second SHA256.sig into the ISO, then create the first SHA256.sig later. For this to work (two SHA256.sig files with the same name but different content) you need to have two directories on all the mirrors, one for the file system images and another for bsd.rd and the sets, or you have to be ok with there being a file inside the ISO that doesn't match the same-named file available from the mirrors. In the end, since any SHA256.sig inside the ISO can't be trusted anyway unless you verified the ISO before you booted it, might as well just leave it out. The only time it's actually useful is if you are installing by booting a verified bsd.rd directly, and downloading the sets during installation (in which case the sets need to be verified after download). I suspect that it's really only for the benefit of people installing this way that the installer verifies SHA256.sig signatures at all. -ken
