Under Microsoft Windows 7 OS, I "burned" install55.iso to a CD which I then inserted into a CDROM slot and rebooted my laptop computer.

When the installation process reached the stage where I had to select some sets, I selected only the ones that I needed.

I was stuck at the next step. I was asked the following:

Quote:

Directory does not contain SHA256.sig. Continue without verification?

What should I do? Can I copy SHA256 and SHA256.sig to a USB flash drive and issue a command to the installation routine, telling it that the required *.sig file is on the USB stick?

Note: I had downloaded both SHA256 and SHA256.sig a few days ago. As the signing key of install55.iso, in the form of *.asc file, is unavailable, there was no way for me to verify the integrity of install55.iso using gpg4win under Microsoft Windows 7.

You hit continue without verification or send a check for $50 for installation CD to Theo de Raadt if you want to be 100% safe. The whole situation sounds pretty hilarious to me since you are using Windows 7 which is well known for its security features.

I didn't mention the fact that I use Debian and Ubuntu from time to time

That doesn't make it less hilarious as Ubuntu is as secure as Windows 7 and Debian is a tiny nitch up. At work we use Red Hat when we have to use Linux (trying to stick with BSDs whenever possible) and I am constantly bewilder by the Linux approach to security. Please don't get me started on that. In particular Debian guys after introducing a major bug into OpenSSL couple of years ago to suppres compilation warnings have zero credibility when it comes to security.

Install OpenBSD twice. Once, without the signify crypto framework available to you. Then reinstall, the second time using it. A minimal installation from your ISO will only require kernels and two filesets: base55.tgz and etc55.tgz, and even on my slowest platform (Alix with compact flash media) this takes about 5 minutes.

Install OpenBSD once, using the unsigned but quite valid SHA256 cryptographic hashes. Download them from an alternate mirror, to be sure the men-in-black haven't corrupted the mirror where you downloaded your ISO, or kernels and filesets.

Until this latest release, Option 3 was the only option available to us. And it is still available to you.

g stands for GNU. Why do you expect to see anything GNU on BSDs? BSDs are completely separate much older family of operaing system direct ancestors Bill Joy's clone of ATT UNIX inspired by Ken Thomson sabatical visit to UC Berkeley 1973.

Unfortunately due to the foolish politics in early 90s traditional BSD system compiler PCC was replaced by GCC and Binutils. GCC is already phased out of FreeBSD and DragonFly BSD but binutils is the only really serious GNU thing found on any BSDs.

The 5.5-release ISOs do not contain a SHA256.sig file, because the ISOs would have required self-signatures. The other installation media options do not have this requirement, which is why the signature file is available outside the ISOs.

Thanks for the suggestion. But I'm technically challenged. I don't have a diploma or degree in IT or computer science.

Quote:

Originally Posted by jggimi

Install OpenBSD twice. Once, without the signify crypto framework available to you. Then reinstall, the second time using it.

That's the suggestion that I'm gonna try. In fact I don't have to install it twice. The first time I install OpenBSD is without the verification using signify.

When I am in OpenBSD OS, I will use signify to verify my earlier downloaded ISO image. If it passes verification, I won't need to reinstall the OS a second time. If it fails, I will have to download the ISO image from another mirror and use the signify app that is on the already installed OpenBSD OS to verify the second-time download.

Quote:

Originally Posted by jggimi

Install OpenBSD once, using the unsigned but quite valid SHA256 cryptographic hashes. Download them from an alternate mirror, to be sure the men-in-black haven't corrupted the mirror where you downloaded your ISO, or kernels and filesets.

For your info, the men-in-black are capable of corrupting all the mirrors of any Linux distro. Take Gentoo for example. One of their apps was infected with a backdoor and all of their mirrors contained the same infected file.

On a side note, I read somewhere that the NSA was planning to create 6,000 IT experts annually.

Finally, the clarification that the ISO images can't be verified using GPG tools.

I thought I had done so an hour earlier, here. But I'm glad this is now clarified for you.

Quote:

For your info, the men-in-black are capable of corrupting all the mirrors of any Linux distro. Take Gentoo for example. One of their apps was infected with a backdoor and all of their mirrors contained the same infected file.

Then I am pleased to inform you that the cryptographic signatures that so concerned you in your posts to this forum to-date ... would not provide any protection for this type of problem, whatsoever.

All that these systems do is prove is that the person with the private key has signed the plaintext, and that it subsequently arrived without change. Any other comfort or feeling of safety you take beyond that simple fact is an assumption on your part.

No digital signature system, including the GPG toolset you are familiar with, can prevent that plaintext from attacks before it is signed, nor protect you if the person who has signed it are themselves a bad actor.

For every one of us who uses software that came from others -- any software, of any kind, on any OS -- requires us to trust. Whether cryptographic signatures are in use, or not.

You may not be aware that successful attacks on cryptographic certification frameworks have occurred many times. And they will occur again. The most recent public announcement of one was two days ago. Whenever they occur, they permit bad actors to portray themselves as trusted authorities.

This inherent weakness in established frameworks is one of the reasons that OpenBSD developed signify(1), as it limits the chain of trust to a single authority.