OpenBSD 5.2 released
undeadly.org
undeadly.org
Detailed Changelog: http://www.openbsd.org/plus52.html
Lyrics for 5.2 Song "Aquarela do Linux": http://www.openbsd.org/lyrics.html#52
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.
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).
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.
You thought you were being witty with this "performing artists" stuff, but really this is just florid ignorance.
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.
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).
Basically, except I meant the key not the signature.
[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.
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.
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.
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.
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?
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.
(former openbsd user, committer, and book author. no, i don't use it any more.)
Mind if I ask why? OpenBSD seems to really chase away developers, virtually everyone who was around back when I paid attention is gone now.
---------------------------------------------
FFS vs. FFS2
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.
[0]: https://en.wikipedia.org/wiki/Native_POSIX_Thread_Library
You're like a grammar Nazi unable to spell check his own posts.
For example, rather than import the quite huge Intel formulated ACPI stack, they have one of the only non-Intel, non-Windows one out there.
See also their reimplementations or forks of SSH, NTP, SMTP, BGP, etc. all done with a security focused mindset.
The point is that this was long overdue. That still stands…
OpenBSD has never been about performance. If anything, I'm wondering why they are destabilizing their product with multi-core threading.
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.)
They ruin everything every 2-3 years instead. Not sure which one is better.
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.