On Tue, Oct 11, 2016 at 11:39 AM, Timothe Litt <tlhack...@cpan.org> wrote:

> On 11-Oct-16 11:14, Dan Collins wrote:
>
>
> 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.
>

You could potentially do some type of functional test in Makefile.PL - try
to run or compile some simple code, and then show an error message/die if
it fails. I believe that all you need to do is have Makefile.PL exit with a
non-zero exit code, but someone else on the list can confirm that.


>
> 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'.
>
>
I'm unfortunately not familiar enough with any modules to offer a
suggestion.


> 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?
>>
>
>
>

Reply via email to