Simplify the openldap code
- No more split for sasl (only an option on by default)
- Modules is now the only way to go
- Remove hidden cldap option
- Use option helpers
Details
Details
Diff Detail
Diff Detail
- Repository
- rP FreeBSD ports repository
- Lint
No Lint Coverage - Unit
No Test Coverage - Build Status
Buildable 26802 Build 25136: arc lint + arc unit
Event Timeline
Comment Actions
Why are we making this change? It was somewhat intentional to not enable SASL by default (to reduce attack surface, e.g. CVE-2019-13565), is this functionality being used by a lot of consumers?
Also note that historically we had two OpenLDAP versions in tree (2.3 and 2.4) for some time, I'm not against adopting a different versioning scheme but the proposed change would make it harder for user to switch between the two, should that happen (and OpenLDAP 2.5 release is imminent).
Comment Actions
yes sasl is used by many end users, as far as I know from personal experience and also from end user reports, SASL is required to be able to properly used the client in most corporate setup including interacting with Active Directory.
With SASL default on, the binary package is good for everyone and the surface of attack is only increased in case someone actually activate SASL which only users who would want SASL would do (am I missing something?)
As for changing the scheme. bsd.ldap.mk is almost useless now that 2.3 is out, we could readd something if 2.5 comes out and we do need both 2.4 and 2.5 to be able to live together. The second things is many maintainers were abusing the WANT_OPENLDAP_SASL even if the documentation claimed it was only for users. defeating its purpose.
Comment Actions
Thinking more about it and considering the imminence of the 2.5 release I think we should in that case to even more changes.
I do think we should only have one LDAP client (possibily the latest) for everyone to use. and reworking the servers so they do not conflict with each other (allowing an admin to use the binary packages for the version of the server they want to deploy in production.)
The servers will come with their own version of the tools and the libraries as well (not conflicting with the default clients).
If you agree with that approach I can work on it and update the review accordingly.
What do you think?