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