I would hope that "OSs that people don't use" do not contribute to the binary size on a different OS, since the relevant source files are just not built for the traget OS.

Of course, the operative word in this sentence is "hope".

The easy example: Because the memory allocator on some systems is slow, OpenSSL had its own malloc implementation (built on top of the system malloc). There was a configure flag to use the system malloc, but because it was seldom used, that didn't actually work. Which meant that because an OS that I don't use has a crappy malloc, I'm stuck with a bigger OpenSSL binary.

This came to be extra-important, because of Heartbleed. The custom malloc both increased the odds that the memory it was accessing but shouldn't be contained something sensitive, rather than just an unmapped page. But it also bypassed the vulnerability-mitigating strategy of OpenBSD malloc, which would have certainly caused a crash, rather than a vulnerability; which would have lead the the issue being fixed.

LibreSSL got the OpenBSD treatment, so the base version is for OpenBSD only, and then there's a portable version for other OSs.

For OpenSSL, I wouldn't know, but fear the worst.

Go see the talk on the reasons for the LibreSSL fork.

Don't just fear the worst, know the worst.

Bob Becks talk on LibreSSL is really informative, scary and entertaining.

https://www.youtube.com/watch?v=-4psTQ1sX7s

This is the other one given by Bob Beck https://www.youtube.com/watch?v=GnBbhXBDmwU - bit different conversation, but same slides

That's the one I was talking about. Sorry, I didn't have the link on me.

Oh, I saw that. I just want to forget it.

The "Big Endian AMD 64 support" slide and discussion should be required viewing in a CompSci ethics class.

Is that the one where they check for endianness changes while the program is running? One of those moments where I was stunned by the stupidity of what I was hearing.

The OSSL outlook is that both the OS and the hardware were designed by untrustworthy, paranoid, schizophrenics who wanted OSSL crash and burn. I wouldn't expect intelligence, sanity, rhyme, or reason.

Yep. Hearing that solution to the problem was just beyond reason. Its like they didn't just set some compile flags and constants for the architecture, but decided that their code had to calculate it every time the variable is needed. The line about finding if /dev/null moved was also pretty scary.

> finding if /dev/null moved

Couldn't find that, do you have a reference somewhere? (I only watched the video that mrweasel posted.)

43:16 into the video I posted

https://www.youtube.com/watch?v=-4psTQ1sX7s

I remember cracking up then forwarding it to all kinds of people and forums. Along the lines of "remember this" if you try to justify trusting the OpenSSL codebase for anything.

...Which is why LibreSSL was started in the first place: Trusting OSSL is fundamentally insane.