undefined | Better HN

0 pointsrollcat10mo ago0 comments

Can you name specific instances where OpenBSD broke POSIX?

Whichever man page I read, they always cite specific standards. They also tend to follow the de facto standards, judging by the breadth of software in their ports tree (which more often than not, is actually full of Linuxisms).

0 comments

3 comments · 1 top-level

spauldo10mo ago· 2 in thread

It's not horribly common. If POSIX mandates something insecure, OpenBSD will often break POSIX in favor of security.

The simplest example is gets(3) doesn't exist in libc. rand(3) and family aren't deterministic (srand_deterministic(3) gives you that, but it's OpenBSD-specific). There are others, but it's not something I think about a lot so I can't think of them off the top of my head.

If you're genuinely interested I'd recommend asking over at DaemonForums. I'm sure someone has compiled a list somewhere.

rollcatOP10mo ago

You're correct. However those sound like perfectly reasonable changes to me. gets(3) is a horrible API.

As defined by POSIX.1-2001:

> If a read error occurs, the error indicator for the stream shall be set, gets() shall return a null pointer, and set errno to indicate the error.

IMHO the least-unreasonable thing to do is to behave exactly as if a read error occurred, but programs that do use gets(3) are unlikely to check for errno anyway.

> The rand() function shall return the next pseudo-random number in the sequence.

<https://pubs.opengroup.org/onlinepubs/007904875/download/> susv3/functions/rand.html

The spec does not say what the sequence should look like, other than it's pseudorandom, so the exact sequence is implementation-dependent. You can't use it to e.g. seed a test run, a terrain generator, etc - and expect repeatable results across platforms, releases. (And I honestly can't think of another reasonable use case for deterministic output.) IMHO at that point you should define your own PRNG, it's about 8 lines of C.

But you're obviously correct, these are deviations.

spauldo10mo ago

The rand(3) thing isn't about repeatability across implementations. Normally if you call srand(3) with the same seed, you get the same sequence of numbers from rand(3). It's useful for testing and debugging. OpenBSD ignores srand(3) altogether. The reasoning is that there are enough cases of people improperly seeding the PRNG that it's worth breaking POSIX to mitigate possible vulnerabilities.

I personally don't have an issue with their choices - they're completely in line with OpenBSD's mission of producing a secure OS. I'd be less pleased to see that sort of thing in other systems like NetBSD, though.

j / k navigate · click thread line to collapse