As I noted previously, distributions with a declared dependency on Crypt::SSLeay may not really need Crypt::SSLeay.
Heartbleed is a serious bug in OpenSSL that allows one side of a “secure” connection to read the memory of the process running on the other side of the connection. While the initial attention focused on clients being able to read confidential data from server processes, clients are also vulnerable.
In a nutshell, you might think your little robot is taking too long fetching stock quotes from remote, but it might just be sucking your memory in 64Kb blocks at a time (yes, there are some details I am glossing over). Host verification may not help you feel secure because, among other reasons, 1) Someone might actually have obtained the certificate for the server via previous attacks on that and might have tricked you into connecting to their server; 2) The server might have been taken over by a hostile party; and 3) The remote might have been legitimately using a self-signed certificate in the past, and you have disabled host verification.
Which means connecting to a remote with a vulnerable client is not safe.
I recently added a test to Crypt::SSLeay 0.65_13 to check for the version of the OpenSSL library it uses which required adding a litte XS to SSLeay.xs. This test fails if the OpenSSL library in use is a version that was revealed to be vulnerable to the Heartbleed bug.
As of 0.65_12, the only failures were coming from machines where IO::Socket::INET was automatically overridden by IO::Socket::IP.
For 0.65_13 version, the current failure rate on CPANTesters is about 75%.
If I leave this test in for the next release, systems with a vulnerable OpenSSL will not be able to automatically update. They will have to force install Crypt::SSLeay.
Now, they may not really need Crypt::SSLeay. LWP might be using IO::Socket::SSL under the covers, but either way, they are depending on OpenSSL to provide a secure communications channel. So, moving to a version of OpenSSL that is not vulnerable would be useful even if Crypt::SSLeay is a superfluous dependency.
Is it worth causing this kind of disruption by having make test for Crypt::SSLeay fail if it was built against a vulnerable OpenSSL?