[seethishat]

They appreciate technical correctness and they do not exaggerate. Most 'security researchers' are not technically correct and they exaggerate a lot (seeking fame and all).

Dismissing their claims is not being selective, it's just the right thing to do.

[strenholme]

Exactly! As an open source developer who has a notable-enough-for-Wikipedia 25-year-old project out there (MaraDNS), let me tell you, a lot of “security bugs” found by AI-assisted researchers are anything but security bugs. Just some examples of stuff which ended up in my inbox recently:

- A security “bug” where someone who sends hundreds of millions of spoofed DNS queries could possibly have one come through. This is a problem with the DNS protocol, and it’s a problem with broken servers which drop DNS packets under some circumstances. It’s a long known issue where, in reality, the exploit isn’t incredibly practical (to say the least).

- A security “bug” where someone saw `strcat` in my code and assumed it was automatically a big huge buffer overflow exploit. No, it wasn’t: I did bounds checking in all cases, except one case where the program in question hasn’t been able to even compile since 2022 (and is a side utility which isn’t needed in any way, shape, or form to run MaraDNS).

- A bunch of security “bugs” which were cases where my recursive resolver took a few seconds to fully drop resources used to solve a DNS query if it got various kinds of weird packets. This researcher claimed one bug was a remote packet of death, so I spent an entire afternoon writing a test case creating the packet in question. Nope, no packet of death.

- Finally, one researcher did find a security bug in the TCP code for the recurisve resolver, where an authorized client could disable the TCP server (without affecting the UDP server). Keep in mind that the code doesn’t enable TCP by default, a user would have to go out of their way to enable DNS-over-TCP, and it’s not a “packet of death” because the IP sending the bad TCP packets has to be one already authorized to perform recursive queries.

With the DNS-over-TCP bug, I patched the code and made a new MaraDNS release. With the overflow in the code which hasn’t compiled since 2022, I fixed the bug, patched the code to compile again, then next removed the code completely from MaraDNS (putting it in “MaraDNS-attic”).

As an aside, djbdns users may have observed that, because of the C23 changes, djbdns doesn’t even compile anymore, and I am not aware of anyone besides myself caring enough to post patches. In my own distribution of djbdns, I have instructed people to set CC to "c99 -D_DEFAULT_SOURCE" so that the code can compile again.

[tredre3]

The fact that most security researches tend to bullshit to pump up their numbers doesn't mean that OpenBSD isn't selective.

The main claim from OpenBSD is "Only two remote holes in the default install since forever".

It is technically true. But it's also selective because they deliberately disable every service by default and don't install any software beyond core.

Once the OS is configured to be useful, we're far from the default install and they would (and have!) refuse to update their motto when confronted with RCEs in those parts.

Which is fair enough! You gotta draw the line somewhere. But that's still being very selective.

[mmooss]

> they deliberately disable every service by default and don't install any software beyond core.

Do you prefer that or everything (or most/many services) being enabled by default? It's a good practice and, for me, very practical - I don't need to find everything I'm not using and disable it.

[stackghost]

Nobody is saying that their minimal default install is itself problematic.

But trumpeting your default install's safety record doesn't actually say much when the default install doesn't actually do anything. As soon as you add a package or a port you're beyond "default install" territory and their vaunted security reputation's coverage.

[mmooss]

I think we agree except one point: IMHO the security of their default install is worth trumpeting: disabling by default is not a technical wonder, but it's good security that others don't do.