If it were me I would remove the verify option completely!!

Why would anyone want to ever NOT verify the cert of gmail.com before sending credentials to it?

It just promotes lack of security by design.

Disabling verification of SSL certs is just a lazy way of developing. There are always better options.

In this exact case no one in their right mind should disable verification - and joomla should not even give them the option.

Of course, just my opinion. It's not like this code has ever worked anyway. Hence the PR to correct it.

@joomla/security

Ping @SniperSister @zero-24 .

Beside that fact that it is a bad idea to use no verification in production we also know that there are enough crape hosts out there with old certificate root.

Anyway the function exists so it should work. If we have 2 tests it can be merged. Removing this feature can be scheduled for j5

@HLeithner Any idea how it can be tested, beside code review?

I go with PhilETaylor,
having a now fixed function, which disables the verification of SSLCerts and haven't even worked when introduced,
is kinda silly.

It is fairly easy to setup a dev/localhost CA/ self-signed SSL cert, so verification could be done that way.

On production, there should be no way to disable the verification of SSL certs.

Hosts which are unmaintained and have old/ outdated SSL Certs have certainly more problems than just invalid SSL certs.
Those hosts should go offline anyway, just to secure the visitors of that site, or otherd because that host ist already hijacked.

But that's just my own 2c.

Either way it has to be fixed: Fix the buggy function like this PR here does, or remove the buggy function. But leave it as it is should not be an option.

@richard67 replace the root certificate for curl with an empty one should work

Dear @SharkyKZ

in preperation of the upcomming release of Joomla 3.10 we have used GitHubs rename feature to rename the staging branch into 3.10-dev. Usually GitHub moves all existing PRs towards the new branch just fine, but here it didnt work. The reason seems to be that the fork of the CMS that was used as base for this PR has been deleted so GitHub does no longer have a base to rebase the PR against the new branch and we are also not able to reopen the PR. For that reason GitHub closed this PR in my name, when this issue is still valid It would require a new PR against the new 3.10-dev or 4.0-dev branch.