Better then reducing security you should add the CA certificate.
PHP 7.1 supports CA certificates for LDAP.

Please write a github PR to add CACERTFILE. Also please check this bug https://bugs.php.net/bug.php?id=73558 if this problem problem still exists (LDAP_OPT_X_TLS_CACERTDIR need to be set).

Parameter we may need:
LDAP_OPT_X_TLS_CACERTDIR
LDAP_OPT_X_TLS_CACERTFILE

@HLeithner as joomla supports earlier versions of PHP your suggestion is not appropriate for joomla core.

the other way is not better :-(

The patch adding this security reduction (for users using it) could simply added in .htaccess

Well, for someone who likes everything in one place and as options where it can be documented .htaccess is not a very good option. As it is the LDAP plugin isn't very well documented and lacks debugging options centrally as well.

My job has always been to streamline and simplify, it helps adoption. Put a large banner above the option which says it's unsafe... Which it really isn't. A self-signed cert is as safe as a bought or let's encrypt as long as you know what it is. Usually this kind of usage is for local access, for internet access use real certs...

It's an option to make usage simpler, that's all... It doesn't change the function.

I have no problem with a self-signed certificate, you only have to add you own CA certificate to the plugin and this would be a great feature.

btw. everything < PHP 7.1 is EOL by the end of this year so supporting new featured that is only valid for this version should be fine, isn't it?

btw. everything < PHP 7.1 is EOL by the end of this year so supporting new featured that is only valid for this version should be fine, isn't it?

No - we have to follow our defined requirements

So no security enhancement even for j4 sounds reasonable.

@HLeithner this is not the place to discuss minimum requirements, backwards compatibility or semantic versioning. Search the tracker its already explained and discussed many times. And welcome to the world of mass distributed software

J4 is still at a PHP 7.0 minimum based on #18562 and lacking a response to #21025 that's not changing anytime soon.

For the most part, we do not introduce features into the core CMS that are only available to newer PHP versions (same applies pretty consistently for things like browsers and database engines), if it cannot be done with the minimum supported version (or in the case of browsers with some form of acceptable fallback, progressive enhancement and polyfills being what they are in this day and age) it's not going to be a feature that core is going to prominently enable. I think the one exception to this right now is the Argon2i password hashing support, but to even make Joomla use it you have to use a plugin that hooks the right events to rehash a plaintext password from Bcrypt to Argon2i so that is going to be a high end use case where the user knows what they're getting into.

Other projects in the PHP ecosystem, and many vendors within the Joomla ecosystem, elect to have faster paced deprecation cycles for when they drop support for legacy platforms. That is entirely up to them. But when contributing here, all code basically must behave pretty close to consistent across all platforms (if you search there are issues regarding transliteration and PHP version support which has blocked doing anything with those functions too) and must be usable to anyone installing a particular version. It would be pretty terrible policy to hide features behind a PHP version check and would be more disruptive than anything (imagine those who build something in a PHP 7.1 local environment then deploy to a 7.0 or 5.6 production environment, or moving a 5.6 locally built site to a live PHP 7.1 environment).

No problem. Brian already stated that this is the wrong place for such a discussion.

Just to comment on adding the certificate to PHP or not, the default for the plugin is non-encrypted ldap so enabling running encrypted ldap with a self-signed certificate (which by the way is default in Windows) is actually a step up in security. :)

Still a userfriendly GUI with complete functionallity is always preferable compared to security by obscurity as we actually are using open-source and not closed source software.

IMHO

As there is a pr for this now #24115 it can be closed here

Just so you all know, the PR i submitted is the exact same patch as I attached to the first message in this Feature Request. I just didn't think of doing a PR at the time.
This could have been resolver half a year ago!

Set to "closed" on behalf of @Quy by The JTracker Application at issues.joomla.org/joomla-cms/21866