Windl, Ulrich wrote:

Hi!

Some comments:

...

A crash, an abort, an assertion failure, or a hang is a **bug**, not a security issue.

So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?

It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.

...

**LMDB trusts its own database files by contract.**

A long time Linux did trust filesystems as well, but some people managed to do bad things by providing manipulated filesystem images (e.g. ISOs). So if some deployment scenario would provide an LMDB image, and that image would cause some buffer overflow, resulting in execution of unwanted actions, wouldn't that be a security bug to care for?

ISO files are, by design, portable formats meant for public exchange. Thus they actually have a significant exposure, by design.

LMDB is an embedded database engine, its files are architecture-specific. It is non-portable by design. Its files are private data, owned by the applications that created them, not meant for public exchange. The security of the files is entirely the responsibility of the applications that created them.

The entire question is ludicrous - when was the last time anyone emailed a BerkeleyDB database file or made it publicly downloadable?

In general I think the guidelines are even a bit too technical for the average user.

The guidelines are aimed at security researchers, with the purpose of discouraging the filing of ordinary bug reports as security issues. Of course they must be technical.

Kind regards, Ulrich Windl

...

-----Original Message----- From: Howard Chu hyc@symas.com Sent: Tuesday, August 11, 2026 6:11 PM To: OpenLDAP Technical openldap-technical@OpenLDAP.org Subject: [EXT] Security policy

Since AI-driven "researchers" are submitting more bug reports these days in hopes of adding CVEs to their CVs, we're probably going to need to publish a more formalized security policy on the openldap.org web site. This is an example of what we're starting with. Feedback welcome.

Brett A C Sheffield wrote:

On 2026-08-12 13:47, Howard Chu wrote:

...

Windl, Ulrich wrote:

...

So a DoS (Denial of Service) (e.g. by crashing the app from remote) is not a security issue?

It does not allow remote code execution, privilege escalation, or privileged data exfiltration. So no, it is not a security issue.

That's an extraordinary position to take.

Remotely stopping code execution certainly gives the attacker something they did not have. Being able to remotely stop your systems from operating at will, with all the associated revenue loss and other impacts that may have may well allow an attacker to achieve their aims completely.

There are three impact categories for CVEs: confidentiality, integrity and availability. Are you really saying that ceding control over availability to an attacker is not a security issue? Being able to, say, shut down a rival phone company at will by killing their directory service seems like a security concern.

Realistically, no company exposes their directory infrastructure to the public Internet. There have been many DoS's via leftover asserts in the code thru the years, but none of these have ever been associated with reports of actual attacks.

You asked for feedback, and I think you should reconsider this. A DoS is a security issue as far as most of the software industry is concerned. Less serious than RCE or LPE, but still of value to an attacker.

Are we talking about the same software industry that thinks LLMs are the coolest thing ever? Arguments based on what the rest of the industry deems important aren't really convincing.

This has been the OpenLDAP Project policy since the beginning, in 1998. We care about data integrity and privacy first and foremost. You can't break the privacy of a downed server.