On Sat Oct 06 01:53:49 2018, DAM wrote:
Show quoted text> In Debian we are currently applying the following patch to
> Net-DNS-SEC.
That is a terrible idea
Show quoted text> Description: load Net::DNS::SEC before using ::libcrypto
> As noted in <
https://bugs.debian.org/909911>, loading e.g.
> Net::DNS::SEC::DSA
> without first loading Net::DNS::SEC fails with
> .
> Died at /usr/lib/x86_64-linux-gnu/perl5/5.26/Net/DNS/SEC/DSA.pm
> line 51.
> .
> This is not cought by the test suite, because all the tests load
> Net::DNS::SEC when they check their pre-requisites.
The test suite only concerns itself with checking that the OpenSSL interface works as expected.
Show quoted text> Explicitly loading of Net::DNS::SEC in the affected modules fixes the
> problem.
which it does not.
Show quoted text>
As is very clear from the documentation, Net::DNS::SEC is an extension to Net::DNS which houses the cryptographic components required for signing and verification of DNSSEC signatures.
There is no supported use-case which requires these components to be compiled independently of Net::DNS. It is entirely a matter for Net::DNS to ensure that packages can be loaded as required.
Net::DNS::SEC::DSA, by design, is intended to fail to compile if either
a) use Net::DNS::SEC is not present in the application,
or
b) DSA has been disabled in the OpenSSL libcrypto component.
Your proposed change undermines that behaviour, and does not allow an application to be built with the DNSSEC features disabled. Moreover, in the case where the application did use Net::DNS::SEC, the additional use declaration achieves absolutely nothing!
It is absolutely essential that no cryptographic feature remain in the code in the absence of "use Net::DNS::SEC" in the application, and especially when a Perl compiler is used instead of the usual interpreter.
[See the warnings in README and in
https://www.openssl.org/source/]
The original PR does not identify any specific failure scenario, version numbers, or any other useful information, so I assume latest versions.
Warnings can be produced if $rrsig->verify() is attempted without first declaring "use Net::DNS::SEC", which IMHO is an unreasonable thing to do, but that should fail in ways a user can understand.
The problem is inside Net::DNS, and a simple solution requires 2 patches:
*** /home/rwf/svn/net-dns/t/65-RRSIG-RSASHA1.t 2018-09-07 09:03:09.447784000 +0100
--- ./65-RRSIG-RSASHA1.t 2018-11-28 23:29:00.215109583 +0000
***************
*** 7,13 ****
my @prerequisite = qw(
MIME::Base64
Time::Local
- Net::DNS::RR::RRSIG
Net::DNS::SEC
);
--- 7,12 ----
*** /home/rwf/svn/net-dns/lib/Net/DNS/RR/RRSIG.pm 2018-09-07 09:03:09.447784000 +0100
--- ./RRSIG.pm 2018-11-28 23:43:40.793424834 +0000
***************
*** 39,44 ****
--- 39,45 ----
use constant EXISTS => join '', qw(r e q u i r e); # Defeat static analysers and grep
use constant DNSSEC => defined( eval join ' ', EXISTS, PRIVATE );
+ use constant ACTIVE => DNSSEC && $INC{'Net/DNS/SEC.pm'}; # Discover how we got here
my ($DSA) = grep { DNSSEC && defined( eval join ' ', EXISTS, $_ ) } DSA;
my ($RSA) = grep { DNSSEC && defined( eval join ' ', EXISTS, $_ ) } RSA;
***************
*** 308,313 ****
--- 309,316 ----
$self->{sigexpiration} = $self->{siginception} + $self->{sigval}
unless $self->{sigexpiration};
+ croak 'missing "use Net::DNS::SEC" declaration' unless ACTIVE;
+
$self->_CreateSig( $self->_CreateSigData($rrsetref), $private );
return $self;
}
***************
*** 384,389 ****
--- 387,394 ----
return 0;
}
+ croak 'missing "use Net::DNS::SEC" declaration' unless ACTIVE;
+
$self->_VerifySig( $self->_CreateSigData($rrsetref), $keyref ) || return 0;
# time to do some time checking.
