On 2026-08-13 11:58, Ondřej Kuzník wrote:
I think you're confusing a critical bug and a vulnerability.
No confusion, just a difference of opinion. A bug is a bug. Whether or not that is considered a security vulnerability generally depends on whether that bug is useful to an attacker.
Being able to crash a service at will can certainly have value to an attacker. That's why one of the three "impact" categories for CVEs is Availability. I've read hundreds of CVEs this year where availability is the only impact. These are handled as security bugs by downstream distributions which package your software. They have CVE numbers. They are subject to disclosure embargos. They are treated as security updates by commercial clients, who will incur reporting obligations under the EU's Cyber Resilience Act from September this year.
The OpenLDAP Project's position appears to be that ceding control of availability to an attacker is not a security issue, just a bug. That's fine. That position puts you at odds with most of the software industry (even those of us who do not think LLMs are cool), which is why I raised it. There is value in standards, and taking a position that is at odds with downstreams, customers and emerging regulations just creates more work for the ecosystem around your project. A DoS will need a CVE even if you decide it is actually a banana.
For a service like OpenLDAP, which is depended on for SSO, logging, recording billing data, call routing etc. it doesn't take much imagination to come up with scenarios where the resulting loss of availability can have value to an attacker.
I agree that a tweak to clarify this is worth making. There might be a way to adjust the description that outlines that distinction yet does not suggest we encourage the perverse incentives of finding literally any bug and insisting it is a vulnerability which is really happening. If you have a suggestion, we're more than happy to adjust, that's the reason we proposed this here first before it lands on the website and maybe repo at some point.
The clarification regarding LMDB trusting its files is useful and gives us something to point at when pushing back against projects (like pylmdb) making unwise assumptions about LMDB. eg. https://bugs.gentoo.org/971352