
Invented by OpenBSD - glass-
http://www.tedunangst.com/flak/post/invented-by-openbsd
======
TodPunk
I've never understood why anyone wouldn't just use OpenBSD if you're going to
use a BSD. I'm sure there are reasons, there must be, but OpenBSD has a long
history of having really great source code that's useful just about everywhere
(hint: you're using OpenSSH almost assuredly on every linux box ever, and it's
fantastic). To me, as a developer I get the whole NIH thing. I really do. I
just don't get why you'd choose "here" to be somewhere that doesn't include
all the amenities in the first place.

~~~
atmosx
Some main differences:

\- LLVM/Clang (it's a matter of taste, but it's also the feature :-) )

\- FreeBSD Jails and Mac (These are extremely strong security features if
implemented correctly. Especially jails are really undervalued/misunderstood
IMHO.)

\- State-of-art network stack (faster than any other BSD or Linux. Supports
technologies like NetMap)

\- ZFS support (important for both desktops/servers)

\- PF version runs on multiple cpus (OpenBSD's version is more advanced
though)

\- DTrace (although not mature enough IMHO)

\- Better hardware support (e.g. wifi cards)

\- BHyve (virtualisation)

\- Capsicum (security)

Other little things like:

\- Unmapped VMIO buffers \- Variable symlinks (used under jails)

Now generally speaking, choosing an operating system due to bigotry and what-
not is stupid. Most of the times, engineers go with what they need: If you
need a secure bastion, OpenBSD gives you more although FreeBSD can be turned
virtually impenetrable as can Linux. OpenBSD comes with more bells and
whistles on this particular area though.

So all in all, it boils to what you need. The major reason why people choose
FreeBSD over OpenBSD is because the 'security level' of the OS is more than
acceptable while retaining a much better hardware support.

~~~
hiphopyo
Can't argue with that, although:

> \- FreeBSD Jails and Mac (These are extremely strong security features if
> implemented correctly. Especially jails are really undervalued/misunderstood
> IMHO.)

Aren't these are only necessary if you let people you don't trust into your
system?

> \- PF version runs on multiple cpus (OpenBSD's version is more advanced
> though)

Personally I dislike running PF on FreeBSD as it requires me to resort to old
docs and use old syntaxes.

> \- Capsicum (security)

Isn't this being ported as we speak?

~~~
Sanddancer
Jails also have resource limits, so you can have a group of processes that are
related, but not started from the same executable, be held to a certain amount
of CPU, memory, etc usage. They're also useful in testing/debug situations;
coupled with ZFS' copy on write features, they let you quickly create
identical environments which can be real helpful in trouble isolation.

------
brynet
"[NetBSD's] reallocarray was [just] fixed to behave like OpenBSD. Now it’s a
13 line replacement for a 10 line function. But at least it doesn’t have any
code written by an OpenBSD developer."

~~~
agumonkey
NihBSD.

~~~
bch
>> Was it really worth replacing one ten line function with another ten line
function just to be different?

> NihBSD

Or SourgrapesBSD ? It's not clear that this was written "just to be
different".

------
kryptiskt
The post on executable memory is a hundred times more interesting than this:
[http://www.tedunangst.com/flak/post/now-or-never-
exec](http://www.tedunangst.com/flak/post/now-or-never-exec)

------
aortega
The article missed:

1) W^X protections

2) ASLR

3) Stack canaries

4) strlcpy

5) OpenSSH!

6) Heap guard pages

7) Software NX

8) Etc.

Maybe project PAX invented some of those, but massive deployment was in
OpenBSD first. Well if you can call them massive..

~~~
foodstances
I think you missed the point of the article.

~~~
aortega
Probably.

Edit: Yes, I missed it.

------
xnull6guest
The changes introduced are potentially extremely damaging. Take for example:

[https://github.com/libressl-
portable/openbsd/search?utf8=%E2...](https://github.com/libressl-
portable/openbsd/search?utf8=%E2%9C%93&q=reallocarray)

~~~
talideon
What's damaging about reallocarray?

~~~
xnull6guest
Did you read the article?

NetBSD's implementation, specifically with regard to how it handles
deallocation, diverges from OpenBSDs - though its documentation is wrong.

LibreSSL (for example) will compile just fine on NetBSD, but as the logic of
the two implementations differ so too will correct memory management in
LibreSSL. This is just one example of how a port of secure code can be made
insecure.

So it doesn't have to do with reallocarray specifically. It has to do with
drawing out the security implications of the article under discussion.

------
fafner
NetBSD's strtoi and strtoimax seem like the better alternative to strtonum.

1\. It is defined for intmax_t instead of long long.

2\. It supports various bases. (At least I regularly need hex or base36)

3\. It can deal with trailing characters.

4\. There are matching strtou and strtoumax operations

It's of course bad if NetBSD introduces an strtonum, which behaves differently
from the OpenBSD one. But maybe the OpenBSD folks should look into strtoi and
strtoimax instead of blindly following their "invented here" principle...

~~~
darklajid
That's basically all mentioned in his post about the design [1] from 2011 and
he seems to dismiss all these cases.

Is that reasonable? No clue, I don't write/know/do C..

1: [http://www.tedunangst.com/flak/post/the-design-of-
strtonum](http://www.tedunangst.com/flak/post/the-design-of-strtonum)

~~~
fafner
I don't think it's reasonable. The way they implemented strtonum might match
their particular use case in OpenSSH/LibreSSL. But if they want to make it a
libc function and popularise it then they should concern themselves with other
use cases and opinions, especially when they pick a bold name as strtonum.
It's not a surprising outcome that others are reluctant to follow them and
they have clashes in behaviour or naming.

------
elchief
Why do people use NetBSD over OpenBSD? Serious question.

~~~
jeffreyrogers
And related, why do people choose *BSD over Linux? (I'm genuinely interested,
and not trying to start a flame war). I've used both OpenBSD and Linux on my
personal computers, but only Linux for servers (mainly due to ease of setup).
My understanding is that Linux has marginally better performance than any of
the BSDs.

~~~
byuu
I initially went back to it over the way systemd was handled on Linux.
Nowadays, I've really grown to appreciate the minimalism and the slower, more
thorough pace of advancements. I find that being _too_ cutting edge just tends
to lead to more problems in production. I also really like the development
model, and most design differences I read about (one quick example:
/dev/random behavior) more in the BSDs. Lastly, lots of features I like a lot
more. ZFS over btrfs, pf over iptables, etc.

~~~
dijit
I always heard good things about the BSD's and I was forced to use pf in my
previous company..

but it was systemd that pushed me towards it, I'm not bound by random binaries
that do random things with little documentation- everything is very clearly
understandable and I can even guess what things will be doing with a large
degree of accuracy.

the whole thing seems much more "sane", but- Linux is a better desktop in my
opinion.

------
alexlarsson
I don't understand how one can claim to "invent" reallocarray. Glib has had
g_realloc_n() since 2010, but its not something being touted as a huge
invention. Its a tiny helper. Very useful, but quite obvious.

~~~
dijit
I think the Author is saying that people often use BSD code or ideas and
reimplement them to be fundamentally incompatible yet using the same name.

this means that, as a developer, when calling these functions you can't be
sure of if you're calling it in a safe way.. openBSD makes code deliberately
designed to be portable, and other BSD's make it non-portable by altering it
in odd ways, yielding dangerous consequences by reusing the namespace.

------
liveoneggs
except the 0 behavior has been restored

~~~
TodPunk
Today. Timestamped almost right with this article. I'm sure it is correlated
and not causal, but I'm also pretty sure the root cause for both is the same.

~~~
clort
I'm not sure what your supposition about the root cause might mean.

NetBSD very recently imported these functions (reallocarray and strtonum) to
libc after much objection (over several years actually) to their poor APIs,
yet finding that they crop up time and again in code used in base (and then
multiple copies exist, in out of the way places). So, as a pragmatic solution
they are now available from libc if _OPENBSD_SOURCE is defined. Cleaner API
functions were proposed, with wrappers which would provide equivalent
functionality for the OpenBSD functions. Some difference was noted, and
recently fixed in these wrappers.

The root cause for the NetBSD changes then, seems to be that these functions
keep cropping up, and the job of libc is to provide commonly used functions.

I believe the intention is, that the cleaner API is proposed to replace the
original OpenBSD ones, which are not properly portable (strtonum for instance,
returns hard coded english error strings in ASCII)

The root cause for the blog entry by Ted Unangst is probably that he is an
OpenBSD developer and was involved in creating these functions, which are now
being criticised.

These root causes don't seem the same to me.

~~~
darklajid
You seem to have a much better understanding of the situation than I do. The
remark about the hard coded error strings was interesting though, so I looked
at the implementation [1].

I .. am not sure why that would be considered not portable? Admitted, I'm
neither into C nor do I have experience in the field, but .. that seems to be
easy to read, contains clear/concise error messages _on top_ of clear error
codes.

1) Any consumer can ignore the string and map the error code to a message in
Klingon or whatever else, no?

2) The function name is in ASCII/English. So are the parameter names. Most of
your C code is probably reading ~somewhat~ like english, and usually is
restricted to ASCII? Is it really a problem that this method returns both a
well-defined number and a simple string in case of an error?

Back to the first line: I .. am certainly clueless here and just watching from
the sidelines. But I'm kinda serious about the questions and genuinely curious
why you object to that part of the implementation?

1: [http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/lib/libc/stdlib...](http://cvsweb.openbsd.org/cgi-
bin/cvsweb/src/lib/libc/stdlib/strtonum.c?rev=1.7&content-type=text/x-cvsweb-
markup)

~~~
clort
for 1, the consumer is properly the user not the programmer.. and the user
cannot ignore the error string in favour of the number if the programmer
provided only that. Since the documentation specifies the error strings,

for 2, the function can be called (as can any C function) from a source
character set other than ASCII, as the compiler should handle that. The name
is technically english its true and programmer needs to know some english,
perhaps.. but the user does not need to know that

if the error code is used, then the error string is superfluous, and C library
functions are not in the habit of providing superfluous information. C is
pretty low level after all.

Here is more reading about the objections the NetBSD folk had with strtonum(3)

    
    
      http://mailing.netbsd.tech.userlevel.narkive.com/mZ37nlai/strtonum-3-from-openbsd

~~~
darklajid
Still confused.

What is a user in your reply? I mean, an end user / my mom isn't going to call
strtonum? Some developer does. And said developer can absolutely ignore the
string's content?

Test for success: errno is 0, errstrp is NULL Handle error: Use errno or
errstrp - the latter gives you a bit more information (reports a different
error for invalid ranges, too small vs. too large).

But if you don't care, errno is fine, no? And we're still talking about the
programmer here, as far as I'm concerned.

Ted has a description of his intentions here [1]. I guess I'm confused why
there's a fuzz about it, because technically this method should be good
enough? I do have to shake my head at the "Even if intmax_t probably would
have been a better choice, I think we’re sticking with long long just because
it frustrates people unwilling to admit it doesn’t make a difference." remark,
but .. other than that? Does it .. matter?

1: [http://www.tedunangst.com/flak/post/the-design-of-
strtonum](http://www.tedunangst.com/flak/post/the-design-of-strtonum)

~~~
clort
Yes, the user is the person who runs the program that they didn't write. They
don't know that they called strtonum()

testing for errno == 0 is not actually useful, since errno is not set except
on error (that is by design of errno, it is always an indication of what the
last error was, not that there was an error)

and errstrp doesn't give the Klingon user you mentioned any information at
all, since they can't read English.

fafner said it better than I in
[https://news.ycombinator.com/item?id=9184734](https://news.ycombinator.com/item?id=9184734)

and yes it does matter, for a standard libc function, because if you don't
take care about setting standards, then your standards will be a mess.

