3 ms·
According to https://openai.com/index/patch-the-planet/ https://openai.com/index/patch-the-planet/ Linux: 24 LPEs, plus many additional vulnerabilities. OpenB
by wahern 3mo ago
According to https://openai.com/index/patch-the-planet/ 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.
- dcrazy 3mo agoOr Linux development is significantly more active.
- ori_b 3mo agoThis is an external audit. Why would Linux activity make a difference here? Are you theorizing that the churn causes bugs?
- tosti 3mo agoWhen 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 3mo agoYes, "en-bugging" :)
- ssl-3 3mo agoI think "embuggening" has better cromulence. Use it as a verb, like embiggening. :)
- Gud 3mo agoNot necessarily. Depends on the quality of the code being written. Quality*Quantity
- Brian_K_White 3mo agoYes 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 3mo agoThere'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.
- throw-qqqqq 3mo agoThe Linux kernel is generally much larger than OpenBSD which is quite minimal. But I do agree with you - not directly related to activity.
- dcrazy 3mo agoAs another commenter said, number of bugs increases with lines of code changed.
- throw-qqqqq 3mo agoI completely agree with that
- rootnod3 3mo agoAnd 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 https://github.com/coreutils/coreutils/blob/master/src/yes.c [2]: https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c https://github.com/openbsd/src/blob/master/usr.bin/yes/yes.c
- ptx 3mo agoJust as another point of comparison, FreeBSD's version seems somewhere in-between. It also enables a Capsicum sandbox before processing any data, akin to what the OpenBSD version does with pledge. [1] https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes/yes.c https://github.com/freebsd/freebsd-src/blob/main/usr.bin/yes...
- rootnod3 3mo agoDifference is that capsicum is after the fact and mostly about file descriptors. You need to open them in advance and _then_ call capsicum. But it does nothing about syscalls. Capsicum is really nice if you plan ahead, but pledge/unveil is easy to drop into any existing code base.
- dwroberts 3mo agoLinux 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.
- asveikau 3mo ago> 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.
- ImJamal 3mo agoIf you add 5 new pieces of hardware support in Linux vs 1 new in OpenBSD, I would expect more issues in Linux.
- _flux 3mo agoI wonder how many of the Linux the LPEs are related to drivers, which I understand there are more of..
- kevincox 3mo agoIt 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.
- acdha 3mo agoLinux 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.
- hulitu 3mo agoLinux 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 3mo agoYes, 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.
- yjftsjthsd-h 3mo agoThat 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)
- 3mo ago
- bigfatkitten 3mo agoLinux LPEs have never been in short supply, even before the AI age.