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.


Reply via email to