Skip Menu |
 

This queue is for tickets about the Net-DNS-SEC CPAN distribution.

Report information
The Basics
Id: 127307
Status: resolved
Priority: 0/
Queue: Net-DNS-SEC

People
Owner: Nobody in particular
Requestors: dam [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 1.11

Attachments
load-Net::DNS::SEC-before-using-::libcrypto.patch



From: dam [...] cpan.org
Subject: [PATCH] load Net::DNS::SEC before using ::libcrypto
Download (untitled) / with headers
text/plain 929b
In Debian we are currently applying the following patch to Net-DNS-SEC. We thought you might be interested in it too. 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. . Explicitly loading of Net::DNS::SEC in the affected modules fixes the problem. Author: Damyan Ivanov <dmn@debian.org> Bug-Debian: https://bugs.debian.org/909911 The patch is tracked in our Git repository at https://salsa.debian.org/perl-team/modules/packages/libnet-dns-sec-perl/raw/master/debian/patches/load-Net::DNS::SEC-before-using-::libcrypto.patch Thanks for considering, Damyan Ivanov, Debian Perl Group
Here's the patch.

Message body is not shown because sender requested not to inline it.

Download (untitled) / with headers
text/plain 3.6k
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.
Download (untitled) / with headers
text/plain 639b
Show quoted text
> 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.
so basically you're saying, running "perl -wc lib/Net/DNS/SEC/DSA.pm" to check for simple syntax errors is not supposed to work for DSA.pm / ECDSA.pm / EdDSA.pm / ECCGOST.pm; this is made even more clear by the error message that was added in 1.11. Which means Debian should remove the patch and exclude those modules from this kind of automatic testing. Which is what I'm doing now, so I think this ticket can be closed. Florian
Resolved in 1.11


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.