On 11-Oct-16 11:14, Dan Collins wrote:
>
> But other modules may work fine with these older versions of the library.
>
Yes, though versions with missing security patches seems like a very bad
idea for all concerned.
>
> And, without testers reporting these failures, you wouldn't know that
> Crypt::PKCS10 is failing on those platforms!
>
It's not failing. An unspecifiable prerequisite isn't being met :-)
Seriously, if it's not met, I don't want to know - though as a good
citizen I think the machine should run safer software.  And I greatly
appreciate test coverage.

> 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.
>
I didn't know that's how to produce an NA.  Thanks.

It's not trivial to do this as the dependency is one level down, OpenSSL
has multiple streams and an unusual version numbering scheme.  About all
I can do is try a higher level function that's sensitive to this, and if
it fails 'assume' that it's a version issue.

A better fix would be for the module that I call, which are closer to
OpenSSL, to complain... I can submit a bug for that.  But they'll have
the same challenges.  And they may want to work with old versions for
some unfathomable reason...

> 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.
>
I do understand the general problem.  However, strongly encouraging the
Smokers to be up-to-date with security-related software seems sensible. 
And however difficult the problem is for CPAN Testers, it's worse for
every module to do its own thing.

I would welcome suggestions of which distributions are 'similar'.

> Regards,
> Dan Collins
>
>
>
>
> On Tue, Oct 11, 2016 at 10:58 AM, Timothe Litt <tlhack...@cpan.org
> <mailto: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
>     <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?
>
>

Attachment: signature.asc
Description: OpenPGP digital signature

Reply via email to