OpenBSD is supposedly one of the most secure OSs in existence. So how is it possible that I cannot find any digital signatures for the downloadable ISOs? I've been searching all over Google and the mirrors, but nothing has come up.
One person has suggested to just order a CD set from them, but I don't think that's a good solution. Having a secure verified copy of an OS should not require ordering a physical "gold master" set of discs to compare against.
I mean, we have all the necessary crypto, and anyone can use it. Generate a GPG/PGP signature of the install ISO and that's it, you're done. A lot of people do it - Debian, Ubuntu, CentOS, all the big names... I mean seriously, even Arch Linux people do it, and until recently they didn't have package signing (now they do).
I'm not complaining or criticising OpenBSD, I'm just wondering about their attitude to this aspect of security. I would be very happy if anyone could elaborate on the topic.
FWIW, literally anyone can sign the OpenBSD releases and say "If your download matches this signature, it's the same as I downloaded from six different mirrors on three continents." Nobody does.
Just because it's signed doesn't mean it is authentic. Do you trust the keys it would be signed with? On the other hand, OpenBSD makes the source available. If you want truly pristine and trusted binaries/ISOs, you should download the source yourself, create your own release (they have docs for this), and sign it yourself. That's the right way to accomplish what you're asking.
I know you can do that, but that's not the best solution. A signature of the install set made with a key known to belong to the OpenBSD project is probably a much better assurance of integrity and authenticity of the files.
Besides, how do you know the files and their hashes are not modified en route to you? One rogue node on the way to you (think AT&T Room 641A, but with data modification abilities) is all it takes, unless the transfer is SSL encrypted. And I don't mean just between you and the mirror, possibly also between the developers and the mirror (I bet some people would be very interested in backdooring one of the most secure systems on the planet by compromising their install images). Modification wouldn't matter as much with a signature-based system, since anyone doing the verification correctly would notice the signature verification failing or the signature coming from the wrong key (see my other comment for more information).
No doubt there are better solutions. But nobody has implemented one yet. Despite some users making up advanced theories for the lack of certain functionality, it usually only comes down to a simple lack of time and resources...
>Generate a GPG/PGP signature of the install ISO and that's it, you're done.
And you are getting that signature from the same place you are getting the binaries you are worried about being tampered with? They don't bother with security theatre because they aren't interested in being performing artists.
Huh? The signing key isn't kept online, unlike the binaries. You "remember" OpenBSD's key once, and can detect if someone tries to replace it with a different key.
You thought you were being witty with this "performing artists" stuff, but really this is just florid ignorance.
I think his point was that many people keep the signature in the same place as the actual binaries (most directories of builds of OSS I've seen have a tarball and a corresponding hash in the same listing).
I'll admit I'm probably ignorant about this, but I don't see the point in that. If someone can compromise the binaries, they can also modify the signature files that are sitting in the exact same place.
It's fine to keep the signature in the same place as the binary. Simply being able to modify files won't allow you to produce a valid signature under a PGP key kept offline.
A signature is not the same thing as a hash or checksum. You could modify an ISO and replace the signature, however that would be your signature. To create a signature as say, the OpenBSD project, you would need their private key, which is (hopefully) carefully hidden on some private machine.
So, putting the signature in the same directory as ISOs is a perfectly safe practice (assuming that strong asymmetric cryptography is used, and the private key is kept private).
And look at all the linux distros that do that. Oh right, they don't. They just go "here's our public key" and people download it over ftp from the exact spot they are getting the binaries, do nothing to verify it, and pretend that got them security. Hence, theatre. Anyone who would actually do it right already has the tools to do so, ssh public keys work just like pgp public keys.
If the binaries get tampered with on the server, then the file will fail the verification. If the signature gets tampered with on the server, the file will also fail the verification. I don't see how any tampering can cause problems, provided the OpenBSD project team publishes their public key widely [0].
[0] There is an attack where the adversary distributes malicious binaries signed with a key that appears to belong to the OpenBSD project, but which in reality would belong to the adversary. This could work if the adversary manages to mislead the user, but if the OpenBSD project team uploaded their public key all over the Internet (and preferably announce it on the mailing lists and home page), then this attack is ineffective. During signature verification, the key ID that created the signature is displayed and the user would know that something is wrong if the signature has not created by the usual OpenBSD signing key.
>If the signature gets tampered with on the server
Sorry, I meant the key. As all the linux distros using PGP signing demonstrate, people don't bother to verify the key, they just accept it blindly and assume everything is cool. Since only 1 out of a million people ask for this, and of those only 1 out of a million would actually go through the correct procedure rather than just grabbing the key from the same place they are grabbing the binaries and not verifying it in any way, it isn't worth the effort. The 0.001% of the 0.001% already have the tools available to verify, it is just a bit of a pain to do. It isn't worth it for the openbsd devs to waste time making it easier for those people who wouldn't verify the key anyways to feel secure when they would be exactly as secure as they are now. That's what I mean by security theatre.
What you mean by security theater is that because some users don't verify binaries, it doesn't matter if anyone is able to verify binaries. You're trolling. Please go away.
Please, keep spamming "ur a troll!!1" like a child, it is very productive and adds a great deal to the discussions at HN. As I said, the 0.001% of the 0.001% who actually want to verify can already do so. Several mirrors have widely known ssh pubkeys.
He doesn't need the PGP key, he tampered with the software before it was signed. I just phrased it that way in response to your absurd statement, a fact that should be painfully obvious. Theo is the guy in charge. He is the guy building the software. He would be the guy signing the software. When Bob owns the build server, he can trick Theo into signing his malicious binaries. Do you think Theo goes through each binary with a disassembler after he compiles them and ensures that the generated binaries are kosher? All PGP would get me is the ability to know Theo signed it. If it was tampered with during the build, or post-build, pre-signing, then I'm boned.
That is the same situation we currently have. If Theo's machines get owned, we're boned. If they don't, we can easily verify that the sha-256 hash of the files on my hard drive, post download from wherever, match those that Theo built.
At the end of the day, you are drawing a line about where to stop verifying and start trusting. The fact that you are download binaries as opposed to source means you are trusting the openbsd developers, not just personally, but in that they have secured access to the code and build process to prevent tampering. So then the only part you aren't trusting is the distribution mechanism, which ssh keys and sha-256 hashes allow you to verify, rather than needing to rely on trust.
"If Theo's machines get owned, we're boned" is not the scenario that signed releases addresses.
No doubt you can concoct a scenario involving malicious robotic brain worms coercing Matthew Dempsky into committing a malicious system call. "PGP doesn't address that!", you'll say, "so it's all just theater".
At the end of the day, you're simply wrong about the utility of release signing. You were mistaken about whether their security was compromised because signatures are fetched from the same location as the binaries (you were tripped up by the concept of "public key cryptography" there). And you were mistaken about the different threat models handled by SSH vs. PGP keys.
I know you aren't actually this stupid, so what exactly is the purpose of your continued trolling? We both know PGP is only covering the distribution portion of the chain. If Theo is owned we're fucked, and if we're owned were fucked (obviously). This is true with PGP, or with what we have now.
So you are saying the openbsd devs should waste time with PGP to solve an issue that is already solved (distribution security). The machine that would be signing the releases is already generating sha256 hashes of them. So as long as you can verify you are getting those hashes from that machine, you are as secure as you can get, PGP or not. And since you can get them over ssh, with a well known public key, you already have everything you need to deal with tampering during distribution. If the machine was compromised and those hashes altered, then it would have been just as much an issue if PGP were in use, since they could alter the binaries before they were signed. You already know all of this, I know you know this, you know you know this, so what are you trying to accomplish by pretending you caught a sudden case of mental retardation?
I love the simplicity and consistency of OpenBSD and everytime Ubuntu changes things like networking or startup script I want to switch out all our servers.
+1 for this. Until recently I had an OpenBSD machine which had an initial install date some time in 1997. I rarely had to change any configs when upgrading. Virtually painless. It was my home mail and db server and was running on an ancient Compaq Pentium Pro 200 with 128Mb of RAM.
It got replaced with Debian due to a complete hardware failure and I already had a Debian CD lying around and couldn't be bothered to download an OpenBSD ISO.
I have used OpenBSD for our servers for a while. It is super easy to setup (except for the brief fun of partitioning). I did switch to FreeBSD with ZFS for our samba server because of the partition size limits on OpenBSD.
I still don't understand this criticism of OpenBSD. I managed to use the installer to set up a fully partitioned OpenBSD system circa version 2.7 as a stoned highschool freshman. I think some people just have trouble using computer programs that require them to use a keyboard and read the documentation.
maybe. took me a few minutes but honestly it got in a number of peoples' ways the first time they saw openbsd's installed way back in the day, and they were no dummies. this is ~1999 mind you, i have no idea since about 2004 what openbsd has been like to install.
True, it really isn't. It is just different and a little weird with commands like 'a a'. After the first time you know all the letters and what partitions to lay down.
Don't you still have to fsck those FFS2 partitions though? That becomes a real problem with very large filesystems. I have been out of the loop for like 7 years now, but I didn't think openbsd offered background fsck or journalling?
Using FFS, OpenBSD supports an individual file system of up to 231-1, or 2,147,483,647 blocks, and as each block is 512 bytes, that's a tiny amount less than 1T. FFS2 is capable of much larger file systems, though other limits will be reached long before the file system limits will be reached.
The boot/installation kernels only support FFS, not FFS2, so key system partitions (/, /usr, /var, /tmp) should not be FFS2, or severe maintenance problems can arise (there should be no reason for those partitions to be that large, anyway). For this reason, very large partitions should only be used for "non-system" partitions, for example, /home, /var/www/, /bigarray, etc.
Note that not all controllers and drivers support large disks. For example, ami(4) has a limit of 2TB per logical volume. Always be aware of what was available when a controler or interface was manufactured, and don't just rely on "the connectors fit".
Larger than 2TB disks
The MBR system used on PCs only directly understands disks up to 2TB in size. fdisk(8) will typically report a disk size of the real size modulo 2TB, so your 2.7TB disk (sold as 3TB) will show as around 700GB in fdisk(8). This does not in any way hinder OpenBSD's ability to utilize larger disks, as the MBR is used only to bootstrap the OS, once the OS is running, the file systems are defined by the disklabel, which does not have a 2TB limit.
To use a larger than 2TB disk, create an OpenBSD partition on the disk using fdisk, whatever size fdisk will let you. When you label the disk with disklabel(8), use the "b" option to set the OpenBSD boundaries (which defaulted to the size of the OpenBSD fdisk partition) to cover the entire disk. Now you can create your partitions as you wish. You must still respect the abilities of your BIOS, which will have the limitation of only understanding fdisk partitions, so your 'a' partition should be entirely within the fdisk-managed part of the disk, in addition to any BIOS limitations.
---------------------------------------------
ZFS on FreeBSD was just a bit easier (for me) for our Samba PDC. Otherwise, I use OpenBSD.
Partitioning in OpenBSD seems a lot simpler in OpenBSD compared to to FreeBSD, but that might just be me. Not a huge problem in any respect, you don't do it that often.
Particulary in the last few releases, the installer will do the partitioning for you, and do it reasonably well, an of course you can always override it.
Nginx now overtakes the default Apache 1 as the new httpd on OpenBSD. In the process of integrating it, OpenBSD already gave back patches for more security (like chroot support). I am very excited about that decision.
OpenBSD has maintained their own hardened fork of Apache 1.x for years. I think that switching to 2.x would be a monumental effort for them and set them back quite a ways in terms of security. I think that nginx is a great move for OpenBSD.
Last I knew, it was less about the effort, more about the license. And if you really need/want Apache 2, it's available in the ports tree and as a package. #> pkg_add apache-httpd
I used to use lighttpd on OpenBSD, but it ended up unusable from some critical SSL library mismatch issue a year or two ago. Switched to nginx and have been incredibly happy.
Sure, 1:1 threading is in fact very old technology. Which makes it all the more astounding that the *BSD's haven't managed to get that technology implemented in their systems until now.
As a result they also have an 8-year stale (and growing) feature set compared with Linux or FreeBSD. And bringing in used, tested, and maintained code from others brings in their bugfixes as well as their bugs.
If you want the new features, use the systems that have them. OpenBSD would have little point to it if it tried to keep up with the Jones'. It has a unique focus - that's why it's useful to some people.
OpenBSD rthreads was started at the roughly same time as the equivalent work in FreeBSD and NetBSD. It took a bit longer, but we got there. And both FreeBSD and NetBSD basically tossed out their first implementation, then rewrote it again. Fun times.
I suppose in some sense OpenBSD "competes" with Linux, but although I don't know for sure, I doubt Theo sits around developing strategies for competing against any other OS. OpenBSD is what he wants it to be, take it or leave it.
People like things to be more faster. Maybe they accept a tradeoff of 10% slower, but 87.5% (one v eight cores) slower? Less likely. Then they run unreliable things instead. Security people don't use isn't secure.
I was told once by a prominent OpenBSD developer that, "threads are for idiots" in response to a bug report that I had made with regard to a threaded program crashing. This was many years ago. I got a laugh from it at the time. Now that I'm older, I sort of feel that he was right.
Installing all the GUI stuff from ports is kind of painful and mostly defeats the security guarantees anyway. OpenBSD is the perfect OS for a router. Everything else is like trying to put square pegs in round holes.
Use FreeBSD on the desktop if you don't like Linux. But I find Debian to be the easiest-to-use desktop OS. (Unlike Ubuntu, they don't randomly ruin everything every 6 months, which is kind of nice. But it still stays up to date with changes that actually matter.)
>Installing all the GUI stuff from ports is kind of painful and mostly defeats the security guarantees anyway
There is no security guarantee, and installing KDE on openbsd gives you better security than installing it on linux. That argument makes no sense at all.
>Everything else is like trying to put square pegs in round holes.
That makes just as little sense. It is a generic unix-like OS. It runs generic unix-like software just like every other generic unix-like OS. Lots of people run openbsd for lots of things, and find it perfectly suitable. The only thing limiting it to routing is your imagination.
Detailed Changelog: http://www.openbsd.org/plus52.html
Lyrics for 5.2 Song "Aquarela do Linux": http://www.openbsd.org/lyrics.html#52