masarati@aero.polimi.it writes:

...

Well, the fact is that memberURL is stored in the data. As soon as we accept that value, we need to deal with it. The current behavior of slapo-dynlist(5) consists in ignoring it (the resulting filter cannot be parsed). We should rather reject values like this when written in the database, but this would probably break other applications. So I believe the fix is better than silently ignoring these values.

I disagree. Data validation in LDAP is generally the user's job, LDAP syntaxes are very rough in that regard.

If this is a fix to make dynlist compatible with the rest of OpenLDAP's handling of URLs in data (e.g. the ref attribute), then this is a good fix and I'm way to late to complain. But in my view, if this fix is introducing an incompatibility with the LDAP spec, then it's not.

Data validation is the user's responsibility, but here we're using user data (an LDAP URI) to perform internal operations, so if we want to be strict, we should do it when the user writes the data, not when we are going to use it. This fix allows the overlay to use poorly formatted data since we cannot prevent the user from using it.

A better fix would be to intercept write operations that modify entries in a manner that would trigger slapo-dynlist(5), and be picky about how URLs are written. This would not fix existing databases, nor handle cases where slapo-dynlist(5) is configured using slapd-config(5).

Or, we could simply become picky about how LDAP URIs are written in general.

p.