It's a tricky balance. I certainly don't want my devices to have a ton of cruft installed which I would never need. But I also certainly don't want to have to spend a month after getting a new device just getting it into usable shape so I can use it for whatever I got it for. I used to think the second concern is very small since I do not get new devices that often, but turns out it's not true, it's often enough that I really want the OS to contain a lot of things from the start. OK, maybe not NetBIOS but wide enough device support and other capabilities so it would be useful for me. And if it's not, I - and most other technically competent, but busy people - would move on to something that provides that service. Goes double for people that are not technical, obviously.

Sure, I don't disagree in principle with the idea that a smaller attack surface is better than a larger one, nor with the idea that explicitly enabling things is better than having to locate and disable services you didn't even know were running.

But saying "only two remote holes" gives the impression that all of OpenBSD is secure and that it's the most heavily scrutinized codebase in the world, it's bulletproof, etc.

It's not.

My toaster hasn't had a remote hole in a heck of a long time either, but then again it doesn't do anything other than make toast.

The default install of OpenBSD doesn't do anything, so the fact that it hasn't had a remote hole in forever isn't saying much.

> Which is almost certainly a combination of the complexities of govt IT procurement, the needs of non-technical users who may only be familiar with Windows & MS Office, and the enterprise management features of Windows that aren't as good in most other OSes.

... and if I were to guess, there's definitely backroom deals between the US government and Microsoft. There's no way all the phone home stuff is even included in "Windows for SCIF".

Yes, but with the exception of sshd (which you get asked about during install), none of these things (NONE!!!) is enabled by default.

I am probably misremembering, but the OpenBSD documentation used to even explain how to disable inetd if you were too paranoid to use that. It is now disabled by default, and--I just checked one of my running systems--my machine does not even have an /etc/inetd.conf file. Most of the things running on a default install are init, cron, slaacd, a handful of gettys, ntpd, syslogd, and sndoid. Arguably sndiod is the only thing you could really remove from that list.

But if you look at the security track record of opensmtpd, you'll quickly see that "Only two remote holes in the default install, in a heck of a long time!" Does not relate to the base system, but to the "default install" - that is; only sshd listening (and possibly pf).

IMNHO more interesting than bickering over the "secure" label, is all the work openbsd has done and is doing to develop stuff like pledge.

You're forgetting their SMTP server had a remote root RCE a few years ago, their IPSec server an authentication bypass, etc.

Both of these were logic bugs and not "insecure C code".

It doesn't matter as they are not enabled by default.

So even if they allow unauthenticated code execution as root or kernel by default when started, it would not count for the "remote hole in default install" claim.

You could as well just not enable network by default. Which makes Windows 95 safer than OpenBSD.

You're not being intellectually honest. Most of those things are disabled by default, so if the httpd had a remote hole, but was disabled by default, then that's not "pArT oF tHe DeFaUlT iNsTaLl" and thus not technically covered by their vaunted claims, and you know it.

So, not OpenBSD, then. I think we're on the same page.