On 2018-02-21, Jean-Michel Pouré <j...@poure.com> wrote: > On Tue, 20 Feb 2018 18:45:01 +0100 > Stefan Sperling <s...@stsp.name> wrote: > >> > I download SHA256.sig abd file sets from mirror, how can I trust it? >> >> You run a trusted signify binary, which was not obtained from the >> mirror but is part of your existing install, to check the signature >> on SHA256.sig. > > 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.
You can't avoid a bootstrap process somewhere. For software using PGP-signing, you need PGP utilities and the right public key. For OpenBSD you need the signify utility and the right public key (e.g. openbsd-62-base.pub). It doesn't matter if the SHA256.sig itself is intercepted because it's signed, when you check it with signify you can spot the modification and know not to trust it. So the main problem moves to getting a trusted signify public key. These are chained back to the first release where signify was used (e.g. go back to a 5.5 or later release from a trusted source, some of these are on CD, and release N includes the key for N+1). Because the keys are relatively short they can be sanely included in various media (you'll find photos and probably videos showing the key printed on some release CDs, plus plaintext mentions in mailing list posts, twitter, mastodon, etc - try searching for one of the public keys itself). untrusted comment: openbsd 6.0 base public key RWSho3oKSqgLQy+NpIhFXZJDtkE65tzlmtC24mStf8DoJd2OPMgna4u8 untrusted comment: openbsd 6.1 base public key RWQEQa33SgQSEsMwwVV1+GjzdcQfRNV2Bgo48Ztd2KiZ9bAodz9c+Maa untrusted comment: openbsd 6.2 base public key RWRVWzAMgtyg7g27STK1h1xA6RIwtjex6Vr5Y9q5SC5q5+b0GN4lLhfu untrusted comment: openbsd 6.3 base public key RWRxzbLwAd76ZZxHU7wuIFUOVGwl6SjNNzanKWTql8w+hui7WLE/72mW > Also I still don't understand the logic of not embedding SHA256.sig in > the ISO. A SHA256.sig exists, why NOT use it? Apart from anything else: at the time the iso and fs files are generated, a SHA256.sig does *not* exist, that is done after the release is built, on a separate machine that only handles signing as part of a locked down process.