[Arubis]

OpenBSD's security stance being the stuff of legend, I'm curious how many vulns have been found over the last couple months while the big model companies are flaunting their ability to find exploits. It'd be super cool to see it remain tiny.

[wahern]

According to https://openai.com/index/patch-the-planet/

Linux: 24 LPEs, plus many additional vulnerabilities.

OpenBSD: 1 LPE.

FreeBSD: 7 LPEs, plus many additional vulnerabilities.

Not sure what that says, though. Perhaps the models are more likely to find Linux issues because of the training.

[_flux]

I wonder how many of the Linux the LPEs are related to drivers, which I understand there are more of..

[dcrazy]

Or Linux development is significantly more active.

[ori_b]

This is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?

[asveikau]

> Are you theorizing that the churn causes bugs?

Seems to be the case.

How many times do you see a bug investigation and it's determined when the bug was introduced?

Do you ever look at the diff that introduced it to understand what was going on in the project at the time? Often, it's in service to a new feature. Sometimes the original change is questionable when you consider you traded it for a severe bug.

[tosti]

When more code is written, more bugs are written.

Or, if the act of debugging is removing the bugs from software, then the act of programming is to put the bugs in the software.

[gnoack]

Yes, "en-bugging" :)

[ssl-3]

I think "embuggening" has better cromulence.

Use it as a verb, like embiggening. :)

[Gud]

Not necessarily.

Depends on the quality of the code being written.

Quality*Quantity

[Brian_K_White]

Yes necessarily. Always. You need to invoke Nasa and fighter jets to find anything coming close, and they only manage to do any better by massive brute overkill in standards & procedures.

[t-3]

There's no plausible level of quality that reduces bugs to zero. More lines being written means more bugs being written, that's a statistical fact.

[dwroberts]

Linux is a much larger project receiving changes to tons of systems from lots of different sources. The combined behaviour of those things working together is massively harder to understand and test.

Copyfail being introduced by an optimization made to some random crypto module is a good example of this.

[ImJamal]

If you add 5 new pieces of hardware support in Linux vs 1 new in OpenBSD, I would expect more issues in Linux.

[throw-qqqqq]

The Linux kernel is generally much larger than OpenBSD which is quite minimal.

But I do agree with you - not directly related to activity.

[dcrazy]

As another commenter said, number of bugs increases with lines of code changed.

[rootnod3]

And some code is absolutely unnecessary. Look at the yes command. GNU version is optimized to death for no reason at all[1].

OpenBSD's version is as simple as it gets[2].

[1]: https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c

[throw-qqqqq]

I completely agree with that

[kevincox]

It is quite possible that Linux is the bigger target so it gets more focus. Vulnerabilities there are generally considered more valuable and notable. It would be very difficult to use these numbers to get a meaningful "more secure" stance as there are tons of variables.

[t-3]

From a quick search, Linux kernel is ~40 million loc, freebsd ~9 million, openbsd ~3 million. Number of bugs compared to lines of code leaves FreeBSD looking worse than Linux.

[mikem170]

I assume those are lines of code in just the kernels.

As an FYI to everyone: The OpenBSD and FreeBSD teams both maintain entire distributions, similar to Linux + Debian or Linux + Redhat. The OpenBSD team also owns a number of other projects - everything from OpenSSH to PF, OpenBGPD, OpenNTPD, OpenSMTPD, OpenIKED, LibreSSL, pledge and unveil, their own set of perl patches, etc.

I'd say that less lines of code seems to correlate with less bugs in absolute numbers, which works out as more secure for those who don't need the extra code.

[acdha]

Linux also has a ton of extra functionality so I think you’d also have to do some adjustment for “as a user would I be at risk?” versus “can I be a user because it supports my needs?” Some of that would be unfavorable for many users (e.g. a Linux user who is exposed due to a network protocol or file system they’ll never use) but that’s certainly not true of every feature.

[yjftsjthsd-h]

That cuts both ways, though. If the functionality is present by default but I'm not using it, that's just extra vulnerability surface. (Of course, if I do want that feature, then its absence is kinda a problem)

[acdha]

Hence the second sentence.

[hulitu]

Linux also has a ton of bloat. Configuring your own kernel has become an exercise in frustration because documentation is worse "There is no help for this kernel option" and a lot of things are enabled "by default".

[acdha]

Yes, that’s why I wrote the second sentence. However, it’s quite an exaggeration that it’s super hard to configure a kernel - distributions can do that for you (e.g. Amazon Linux disabled a bunch of drivers for hardware you’ll never have in EC2), modules can easily be disabled (common remediation for those IPsec accelerators earlier this year), and it’s not that hard to build your own kernels and distribute them on most popular distributions.

[dspillett]

If this is just counting the kernel, than Linux is probably a bigger target both i terms of current code size and the amount of churn in the codebase as things change over time. Some of the LPEs might (I've not checked) be in modules that are not commonly loaded, which mitigates their overall significance somewhat.

In the less likely even that this is counting what laymen would call Linux or BSD, i.e. both the kernel and common libraries & tools, then Linux definitely has a wider attack surface. Though some of that surface is shared as some userland parts are common to both.

As with your assessment, I'd agree that these flat numbers without looking for further context don't really give enough for a one-is-more-or-less-secure statement.

[bigfatkitten]

Linux LPEs have never been in short supply, even before the AI age.

[ectospheno]

The commit logs over the last few months have highlighted when an issue was found by a program. They usually name the submitter and the tool.

[mmooss]

I think of it more as their attention to quality in their code:

Given the 'quality' of most code, especially under commercial pressure, it's no surprise that much more effective tools will find many more vulnerabilities. Did OpenBSDs quality approach work in this respect?

[bee_rider]

A local escalation in BSD is still apparently worth a front page post here, so that seems pretty good.

I wonder why we don’t see more about local escalations in Windows. Of course, being closed source is a little bit of a barrier, but these tools can read assembly pretty well, right?

[acdha]

I’ve heard a couple people say that Microsoft has patched a record number of bugs internally this year so it might be the case that it’s simply more opaque because it’s initiated internally and doesn’t involve a public Git repo or a third-party researcher.

[bigbuppo]

You don't hear about them because you're probably not paying attention to where all the Windows admins hang out. Nearly every single patch tuesday over the past couple of years has been an emergency race to get things patched as soon as you can, for both local and remote exploits.

[JCattheATM]

> OpenBSD's security stance being the stuff of legend,

More so their marketing.

[throwaway27448]

What does openbsd marketing look like?

[c22]

Mostly Comic Sans.

[eukara]

only on some operating systems.

[JCattheATM]

Pretty sure you're familiar with their claims.

[throwaway27448]

I'm not actually, because I'm damn sure I've never seen a piece of openbsd marketing in my life. All i know is that they're oriented around security and are notorious about rejecting patches.

[JCattheATM]

> I'm damn sure I've never seen a piece of openbsd marketing in my life

Kind of weird for you to defend a product if you've never even been to their website.

[chlorion]

Yes, you know that because of their marketing.

[throwaway27448]

Do you have an example of this?