I think you can safely use the Makefile.PL to decide if the current OpenSSL
available has the minimum expected interface and cause a "NA" in the case it
doesn't.
You can generate a "NA" with die() on the Makefile.PL. One good example of that
is Devel::CheckOS.
If you add to that the declaration of minimum version of OpenSSL, I think
you'll be OK.
OpenSSL is a project that has known problems and a lot of people depend on it.
Not sure if the OpenBSD's replacement LibreSSL will be able to replace it on
the future, but I think that would be great.
De: Timothe Litt <[email protected]>
Para: "[email protected]" <[email protected]>
Enviadas: Terça-feira, 11 de Outubro de 2016 12:39
Assunto: Re: Test system configurations
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 <[email protected]> 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:
- 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.
- 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/wi ki/SmokeTesting says:
Provide a update version of OpenSSL development files. That configuration will
vary from your operational system, but OpenSSL is required by default by
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.
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?
