But other modules may work fine with these older versions of the library.
And, without testers reporting these failures, you wouldn't know that
Crypt::PKCS10 is failing on those platforms!
I suspect that you want to probe for the OpenSSL version at the Makefile.PL
stage, and if there is an insufficient version, fail there. This will
prompt real users to upgrade to a supported version (be sure that the
message shows what version of which library you require, and ideally,
explains why), and it will cause CPAN testers to report either NA (which
means we couldn't test your distribution) or not at all, instead of
reporting FAIL.
CPAN Testers machines are operated by many different users, including both
Smokers (which run automated testing) and regular users (which send reports
of distributions they install manually). It isn't practical to require a
set of ever-changing minimum library versions, especially given the many
different platforms in use. Instead, I suggest you inspect similar
distributions for a way to bail out at the Makefile.PL stage on unsupported
OSes, or with unsupported library versions.
Regards,
Dan Collins
On Tue, Oct 11, 2016 at 10:58 AM, Timothe Litt <tlhack...@cpan.org> wrote:
> Recently, I released a CPAN module (Crypt::PKCS10 v1.7/8) that uses
> modules which depend on OpenSSL.
>
> I've seen quite a few test failures (11 on v1.8) from systems that are
> running OpenSSL version 9.8.something.
>
> That version, and 1.0.0 stream are out of support, have security issues,
> and should not be run by any production site. So I consider the test
> failures invalid.
>
> This raises two questions:
>
> 1. What versions of system libraries should the test pools have? I
> think it's reasonable and desirable to run old OS versions, as they exist
> in the wild. (I even run some...) But where serious security issues exist
> and the library is upgradable independent of the OS, I think that those
> upgrades (and all security patches) should be required.
> 2. Is there a way specify requirements like this as prerequisites? In
> my case, I depend on Crypt::OpenSSL::{RSA,DSA}. These aren't my modules.
> But even if they were, they will build against the old libraries and keep
> working without rebuilding indefinitely. And the version of OpenSSL is
> independent of the version of any module that calls it... CPAN::Meta::Spec
> doesn't seem to address this scenario.
>
> I could try to check for a reasonable version in my tests - but they'd
> still fail. My current approach is to attempt to print out the OpenSSL
> version, so at least it's easy to diagnose the problem.
>
> But 'reasonable version' is a moving target, and really should gate
> the install, not the test...
>
> I could exit with "Pass", but that would be a lie.
>
> http://wiki.cpantesters.org/wiki/SmokeTesting says:
>
> Provide a update version of OpenSSL <https://www.openssl.org/> development
> files. That configuration will vary from your operational system, but
> OpenSSL is required by default by CPAN-Reporter
> <http://search.cpan.org/dist/CPAN-Reporter> for sending the tests reports
> and updated versions of Perl related distributions will not accept very old
> versions of OpenSSL. If you're without luck to get an updated version or is
> not the administrator of the OS, check this article
> <http://slashlogging.blogspot.com/2015/01/installing-openssl-inside-your-perlbrew.html>
> .
>
>
> That's a start, but not quite strong enough. Perl is quite happy with
> old, insecure versions of OpenSSL.
>
> I suggest that test systems should be up to date with available libraries
> and security patches. Admittedly, only a partial solution. But it covers
> my case :-(
>
>
> Thoughts?
>
