OpenBSD 5.5 has been released. As usual, the list of changes goes way beyond my comfort zone – I’m not exactly into the world of BSD – but I’m pretty sure that those that use OpenBSD aren’t interested in oversimplified nonsense from people like me anyway.
As always, get it on CD-ROM (I love typing that in this day and age), or straight from a mirror.
Hell yeah!
Although, as always, by this time -current is more attractive for desktop and elsewhere except servers in production.
OpenBSD 5.5 is, as far as we can tell, the first operating system that beats the Y2K38 bug.
The Y2k bug wasn’t more than slight annoyance.
The Y2K38 bug is really serious.
All Unix(like) operating systems count time in seconds beginning at Midnight on January 1 1970. The counter is 32 bits and is a signed value.
That means that we have a clock that can count up to
0111111111111111111111111111111 = 2,147,483,647 seconds
which happens to be (in date terms) Tue Jan 19 03:14:07 UTC 2038.
One second later the clock will have all ones and the number is negative.
That results in a clock at 2,147,483,648 which will show the date as: Friday Dec 13 1907.
It could be real fun if you are on an automatic drip in hospital when the clock jumps that far back.
I’m sure you can think of other problems.
For further info see http://www.openbsd.org/papers/eurobsdcon_2013_time_t/
Edited 2014-05-01 11:39 UTC
According to the Wikipedia page, NetBSD 6.0 (released Oct 2012) has remedied it. It uses a 64-bit value in 32- and 64-bit versions, and provides a compatibility layer for older apps that expect a 32-bit unsigned integer.
OpenBSD does the same, but doesn’t provide a compatibility layer for apps that expect 32-bit values.
The Linux x32 ABI (for running 32-bit apps within x86 64-bit Long mode) uses a 64-bit integer, also.
The Wiki also says most 64-bit Unix systems use a 64-bit value.
Sarcasm?
If not I would like to quote this part from the link you posted: An alert reader was kind enough to point out that IBM PC hardware suffers from the Year 2116 problem. For a PC, the beginning of time starts at January 1, 1980, and increments by seconds in an unsigned 32-bit integer in a manner similar to UNIX time. By 2116, the integer overflows.
Windows NT uses a 64-bit integer to track time. However, it uses 100 nanoseconds as its increment and the beginning of time is January 1, 1601, so NT suffers from the Year 2184 problem.
On this page, Apple states that the Mac is okay out to the year 29,940!
Sarcasm! Indeed…
Considering that Apple abandon support of their past product after 3 or 5 years due to planned obsolescence, I see really no point at advertising for a clock support up to 29K.
Their should tweak their clock to stop functioning at the end of support. Hence you would know how much time left you have to save your document.
Kochise
Edited 2014-05-01 13:12 UTC
Forsooth!
YALoki,
“OpenBSD 5.5 is, as far as we can tell, the first operating system that beats the Y2K38 bug.”
Actually, I would have thought most had already migrated to 64bit interfaces, no?
“It could be real fun if you are on an automatic drip in hospital when the clock jumps that far back.”
That’s an interesting theory, but I’d be surprised if any of that was actually date sensitive in the first place. Has anyone seen this equipment? Even assuming there is an internal timer that does roll around within the useful lifespan of the equipment, mathematically speaking the overflow wouldn’t affect rate calculations in finite integral variables.
For example, let T0 equal the largest signed integer, which is 2147483647 (2^31-1). Now let T1 equal the largest signed integer plus a positive delta d1. Obviously this can not be represented, and in binary/twos complement would wrap around to -2147483649 + d1.
This seems like a big problem, however a naive time difference (T1-T0) will still give us the correct answer due to the fact that computation of low order bits are not dependent upon the high order bits that overflowed and are lost.
Ostensibly, T1 – T0 should equal d1:
-2147483649 + d1 – 2147483647 =? d1
-4294967296 + d1 =? d1
This looks completely wrong, until you look at it in binary:
1111111111111111 0000-0000 0000-0000 0000-0000 0000-0000
The error is in bits that are not represented by a 32bit number, in other words we knew they were wrong already and we don’t care that they are wrong here since all the bits we keep are actually correct.
So this becomes 0 + d1 = d1, which is true.
Who knows what overflow bugs might be introduced in real code (ie java would throw exceptions, which could ironically be more harmful than C’s overflow), but I’m just pointing out that overflows aren’t mathematically significant for relative time.
Edit: Of course this all assumes that the math is done with the same 32bit representation. I think many applications will convert the absolute time to a floating type strait away because that can be more useful to work with.
Edited 2014-05-01 14:49 UTC
More thoughts, I guess it’s not a forgone conclusion that a program would use relative time.
I just tested sizeof(time_t) on my system and it’s 8, and as far as I know that’s already been the case for a long time already (anyone catch the pun?).
For embedded devices that depend on absolute time, you could just tell them it’s 1980s and they’ll be good for another few decades. A dead cmos battery will probably reset the clock anyways
So it seems the primary risk is for embedded devices that 1) have a lifetime of decades on end, and 2) contain a program that depends on absolute time, 3) keep the correct time set, and 4) run the same software indefinitely without a recompile.
Edited 2014-05-01 16:04 UTC
Not on 32 bit CPU, no.
And Linux x32 isn’t used apparently, too bad: best performance and no Y2K38 issue..
If someone is considering moving to OpenBSD as a secure server right now, please be aware that this release as sold in CD and available from HTTP mirrors contains a vulnerable version of OpenSSL and needs to be patched by recompiling OpenSSL following the instructions available on the OpenBSD web site. If you aren’t comfortable doing that and need HTTPS and similar, you should wait until 5.6 which will include the refurbished LibreSSL. This release is otherwise a nice one including OpenBSD signed packages, 64 bit time_t and improved Open source Radeon support.
Patching OpenSSL in OpenBSD 5.5 is no different than installing any other security or reliability fix. If you’re not up to installing security fixes, waiting for the next release isn’t going to do you any good.
And yes, it’ll be nice when we can use LibreSSL, but why in the world would you recommend not switching until that’s ready? It’s not available for other OSes (I can guess which you use) but I don’t see you telling people to avoid those…
tl;dr: don’t listen to the guy above me.
In other OpenBSD and OpenSSL news OpenSSH doesn’t depend on OpenSSL anymore:
http://it.slashdot.org/story/14/04/30/1822209/openssh-no-longer-has…
I run current, mind you. That is the only long term security option.
For releases, usually security and reliability fixes are not critical security holes and in parts of base you might not even be using. Some releases had no errata at all before the following release.
Realistically, most people avoid touching working systems. No it is not good, but you can see on the mailing lists that someone periodically asks how to update from 4.5 to 5.x. Do you think they are going to recompile from source once their uptime is larger than zero?
Starting with a release which is vulnerable to a widely known and trivial remote exploit is very dangerous in that context. There is no good way to install a patched system without installing a vulnerable one first.
Unlike most critical security holes to date, with Heartbleed one can get at your data without targeting OpenBSD specifically. It is 100% guaranteed your data will be stolen from a public facing server. My systems are okay but I don’t want identity theft platforms all over the web.
Yay! I have 5.4 installed on a partition right now, my first experience with OpenBSD with which I’ve been EXTREMELY impressed. I’m looking forward to reading the amazing documentation and doing my first OpenBSD system update.
You’ll need to recompile anything you built from source on that machine. There’s an ABI break between 5.4 and 5.5 due to the time_t size switch.
That was intended and obvious.
a) You have the source code to recompile using 64-bit time_t.
and
b) The code you recompile doesn’t use a “long” (aka 32-bits) to store the time in.
So fine for ISOs of distros where all the source is available and can fixed for any issues, but no good for “bad coding practice” or any closed source software that can’t be re-compiled.
Fortunately OpenBSD cares little for those two cases.
There are now USB flash drive images available. Before I had to install OpenBSD on a flash drive inside Bochs before I could install it on my PC without an optical drive. Which was a bit of an inconvenience.
You don’t need an usb image to install OpenBSD in the past. They provide floppy images so any BIOS with the ability to do USB-FLOPPY emulation was enough to boot the OS (and installer) and then read the files from anywhere.
Also some BIOS can boot from the ISO image (dumped on the USB).
If you are upgrading an OpenBSD installation, it’s easy to copy all CD files to a usbdrive, and the redirect the bootloader of the hardrive to the bsd.rd file of the usbdrive. Something like:
> boot hd1a:/5.5/amd64/bsd.rd
(assuming that hd0 is the hardrive and hd1 the usbdrive).
If you are upgrading a Linux installation, you can boot the floppy image or the bsd.rd file from grub.
Thank you, I didn’t know any of this.
That’s not very secure…
Edited 2014-05-01 16:02 UTC
It totally depends on how you use it.
It was a play on words – either the future of bitcoin is not secure, or its value is not secure.
Not everyone in the world have access to a reliable, fast and inexepensive internet connection. The old fashion mail may still be the most effective way of distribution of large software packages such as an operating system.
Almost certain it is enterely free from infections. Unless the source code tree of the project was somehow infected, the probability of the package received on optical media being infected is extremely low.
Finally, if one is un-satisfied with the experience, one can recycle the media as a coffe cup coaster, frisbee, decoration (needs an attractive design/logo on the top face), and probably many other second uses not yet thought about.