Linked by Thom Holwerda on Thu 1st May 2014 10:18 UTC
OpenBSD

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.

Order by: Score:
Awesome
by judgen on Thu 1st May 2014 10:36 UTC
judgen
Member since:
2006-07-12

Hell yeah!

Reply Score: 4

RE: Awesome
by ddc_ on Thu 1st May 2014 11:50 UTC in reply to "Awesome"
ddc_ Member since:
2006-12-05

Although, as always, by this time -current is more attractive for desktop and elsewhere except servers in production.

Reply Score: 3

Something special in 5.5
by YALoki on Thu 1st May 2014 11:25 UTC
YALoki
Member since:
2008-08-13

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

Reply Score: 7

RE: Something special in 5.5
by Drumhellar on Thu 1st May 2014 11:56 UTC in reply to "Something special in 5.5"
Drumhellar Member since:
2005-07-12

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.

Reply Score: 7

RE: Something special in 5.5
by avgalen on Thu 1st May 2014 11:56 UTC in reply to "Something special in 5.5"
avgalen Member since:
2010-09-23

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!

Reply Score: 2

RE[2]: Something special in 5.5
by Kochise on Thu 1st May 2014 13:11 UTC in reply to "RE: Something special in 5.5"
Kochise Member since:
2006-03-03

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

Reply Score: 6

RE[2]: Something special in 5.5
by kwan_e on Thu 1st May 2014 15:56 UTC in reply to "RE: Something special in 5.5"
kwan_e Member since:
2007-02-18

However, it uses 100 nanoseconds as its increment and the beginning of time is January 1, 1601


Forsooth!

Reply Score: 2

RE: Something special in 5.5
by Alfman on Thu 1st May 2014 14:35 UTC in reply to "Something special in 5.5"
Alfman Member since:
2011-01-28

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

Reply Score: 3

RE[2]: Something special in 5.5
by Alfman on Thu 1st May 2014 16:02 UTC in reply to "RE: Something special in 5.5"
Alfman Member since:
2011-01-28

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

Reply Score: 3

RE[2]: Something special in 5.5
by renox on Fri 2nd May 2014 09:18 UTC in reply to "RE: Something special in 5.5"
renox Member since:
2005-07-06

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?


Not on 32 bit CPU, no.
And Linux x32 isn't used apparently, too bad: best performance and no Y2K38 issue..

Reply Score: 3

Heartbleed alert!
by sakeniwefu on Thu 1st May 2014 12:15 UTC
sakeniwefu
Member since:
2008-02-26

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.

Reply Score: 7

RE: Heartbleed alert!
by IsakWatertroll on Thu 1st May 2014 18:49 UTC in reply to "Heartbleed alert!"
IsakWatertroll Member since:
2014-05-01

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.

Reply Score: 2

RE[2]: Heartbleed alert!
by Lennie on Thu 1st May 2014 20:50 UTC in reply to "RE: Heartbleed alert!"
Lennie Member since:
2007-09-22

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...

Reply Score: 2

RE[2]: Heartbleed alert!
by sakeniwefu on Thu 1st May 2014 23:43 UTC in reply to "RE: Heartbleed alert!"
sakeniwefu Member since:
2008-02-26

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.

Reply Score: 3

Comment by drcouzelis
by drcouzelis on Thu 1st May 2014 12:39 UTC
drcouzelis
Member since:
2010-01-11

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. ;)

Reply Score: 2

RE: Comment by drcouzelis
by tidux on Fri 2nd May 2014 16:57 UTC in reply to "Comment by drcouzelis"
tidux Member since:
2011-08-13

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.

Reply Score: 3

RE[2]: Comment by drcouzelis
by 0brad0 on Sat 3rd May 2014 07:56 UTC in reply to "RE: Comment by drcouzelis"
0brad0 Member since:
2007-05-05

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.

Reply Score: 2

time_t fix works, but only if...
by rklrkl on Thu 1st May 2014 14:30 UTC
rklrkl
Member since:
2005-07-06

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.

Reply Score: 3

Soulbender Member since:
2005-08-18

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.

Reply Score: 2

USB flash drive images
by righard on Thu 1st May 2014 15:14 UTC
righard
Member since:
2007-12-26

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.

Reply Score: 3

RE: USB flash drive images
by KrustyVader on Thu 1st May 2014 15:57 UTC in reply to "USB flash drive images"
KrustyVader Member since:
2006-10-28

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).

Reply Score: 2

RE[2]: USB flash drive images
by KrustyVader on Thu 1st May 2014 16:51 UTC in reply to "RE: USB flash drive images"
KrustyVader Member since:
2006-10-28

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.

Reply Score: 2

RE[3]: USB flash drive images
by righard on Thu 1st May 2014 17:35 UTC in reply to "RE[2]: USB flash drive images"
righard Member since:
2007-12-26

Thank you, I didn't know any of this.

Reply Score: 2

Payment in...
by kwan_e on Thu 1st May 2014 16:02 UTC
kwan_e
Member since:
2007-02-18

Bitcoin
Bitcoin is accepted.


That's not very secure...

Edited 2014-05-01 16:02 UTC

Reply Score: 3

RE: Payment in...
by Lennie on Thu 1st May 2014 23:13 UTC in reply to "Payment in..."
Lennie Member since:
2007-09-22

It totally depends on how you use it.

Reply Score: 2

RE[2]: Payment in...
by kwan_e on Fri 2nd May 2014 12:07 UTC in reply to "RE: Payment in..."
kwan_e Member since:
2007-02-18

It was a play on words - either the future of bitcoin is not secure, or its value is not secure.

Reply Score: 3

BlueofRainbow
Member since:
2009-01-06

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.

Reply Score: 3