Bug #128207 for Net-SSLeay: Fails t/local/06_tcpecho.t and t/local/07

Wed Jan 09 22:07:24 2019 KENTNL [...] cpan.org - Ticket created

Subject:

Fails t/local/06_tcpecho.t and t/local/07_sslecho.t under network sandbox

Gentoo executes package tests under a network sandbox that's supposed to prevent external network IO, while still having local network IO within the sandbox.

However, under these conditions, most tests run properly, including the network consuming ones ( in that they just auto-skip instead of failing )

But 2 tests in the "local" test suite currently fail for whatever reason:

t/local/06_tcpecho.t actually runs indefinitely with a hung child blocked in accept()

t/local/06_tcpecho.t ...................
1..4
Use of uninitialized value $got in string eq at t/local/06_tcpecho.t line 66.

    63   my @results;
    64   {
    65        my ($got) = Net::SSLeay::tcpcat('localhost', $port, $msg);
    66        push @results, [ $got eq uc($msg), 'sent and received correctly' ];
    67   }

t/local/07_sslecho.t actually finishes, but indicates some problem interfacing with Socket.pm:

t/local/07_sslecho.t ...................
1..78
Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 at /usr/lib64/perl5/5.26.2/x86_64-linux/Socket.pm line 834.
Show quoted text

# Looks like your test exited with 11 just after 51.

Dubious, test returned 11 (wstat 2816, 0xb00)
Failed 78/78 subtests

Its not clear to me why these tests only *now* fail for me, despite being fine months ago, but I have openssl 1.1.0j installed now, and that *could* be a significant factor

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Thu May 02 11:22:44 2019 chrisn [...] cpan.org - Correspondence added

Thanks for the report, Kent --- apologies for taking so long to get back to you. On Thu Jan 10 03:07:24 2019, KENTNL wrote: Show quoted text

> Gentoo executes package tests under a network sandbox that's supposed > to > prevent external network IO, while still having local network IO > within the > sandbox. > > However, under these conditions, most tests run properly, including > the network > consuming ones ( in that they just auto-skip instead of failing ) > > But 2 tests in the "local" test suite currently fail for whatever > reason:

t/local/06_tcpecho.t and t/local/07_sslecho.t are notable for being the only two tests in the test suite to use localhost instead of 127.0.0.1, so I bet it's because of that. Show quoted text

> t/local/06_tcpecho.t actually runs indefinitely with a hung child > blocked in > accept() > > t/local/06_tcpecho.t ................... > 1..4 > Use of uninitialized value $got in string eq at t/local/06_tcpecho.t > line 66. > > 63 my @results; > 64 { > 65 my ($got) = Net::SSLeay::tcpcat('localhost', $port, $msg); > 66 push @results, [ $got eq uc($msg), 'sent and received correctly' ]; > 67 }

The call to Net::SSLeay::tcpcat() involves an implicit call to gethostbyname() to resolve localhost, which presumably never returns because Perl can't use the resolver (this apparently also happens on Gentoo when one emerges a package in which autotools checks for gethostbyname() [1]), which would explain the long delay --- gethostbyname() should eventually time out and return, but the call to tcpcat() would then fail anyway, so there'd be no hope of the test passing. Show quoted text

> t/local/07_sslecho.t actually finishes, but indicates some problem > interfacing > with Socket.pm: > > t/local/07_sslecho.t ................... > 1..78 > Bad arg length for Socket::pack_sockaddr_in, length is 0, should be 4 > at > /usr/lib64/perl5/5.26.2/x86_64-linux/Socket.pm line 834. > # Looks like your test exited with 11 just after 51. > Dubious, test returned 11 (wstat 2816, 0xb00) > Failed 78/78 subtests

t/local/07_sslecho.t explicitly tries to resolve localhost using gethostbyname() instead. When that also fails, gethostbyname() returns undef, which sockaddr_in() then can't pack as an IPv4 address ("length is 0 [bytes], should be 4"), leading to the error. There's another use of localhost in this test too, in a call to Net::SSLeay::sslcat(). Show quoted text

> Its not clear to me why these tests only *now* fail for me, despite > being fine > months ago, but I have openssl 1.1.0j installed now, and that *could* > be a > significant factor

Strange indeed. In any event, the solution ought to be simple: replace localhost with 127.0.0.1. I don't have easy access to a Gentoo installation, so would you mind running the tests from this branch in your sandboxed environment to see if that solves the problem? https://github.com/chrisnovakovic/p5-net-ssleay/tree/RT-128207-tests-remove-localhost If it does, I'll merge that branch into the main repository. [1] https://forums.gentoo.org/viewtopic-t-749921-start-0.html

Thu May 02 11:22:45 2019 The RT System itself - Status changed from 'new' to 'open'

Thu May 02 11:22:45 2019 chrisn [...] cpan.org - Taken

Sat May 04 12:13:27 2019 chrisn [...] cpan.org - Correspondence added

RT-Send-CC:

KENTNL [...] cpan.org

On Thu May 02 16:22:44 2019, CHRISN wrote: Show quoted text

> Strange indeed. In any event, the solution ought to be simple: replace > localhost with 127.0.0.1. I don't have easy access to a Gentoo > installation, so would you mind running the tests from this branch in > your sandboxed environment to see if that solves the problem? > > https://github.com/chrisnovakovic/p5-net-ssleay/tree/RT-128207-tests- > remove-localhost > > If it does, I'll merge that branch into the main repository.

I've had some time to look into testing this myself, and it seems to work fine (assuming what I'm doing is sensible: I've never used Gentoo before, so that's not a guarantee). I built a fake Net-SSLeay-1.86_10.tar.gz "release" based on the Git branch above, and wrote a Net-SSLeay-1.860.0.ebuild based on Net-SSLeay-1.850.0.ebuild [1]. This involved minor changes to the "fix-dir" and "fix-network-tests" patches in files/, because we've dropped Module::Install in favour of ExtUtils::MakeMaker since 1.85. In a VM booted into the LiveDVD environment, I then set up a local Portage repository in /usr/local/portage/ containing only dev-perl/Net-SSLeay and added "test network-sandbox" to FEATURES in /etc/portage/make.conf. "emerge -atv dev-perl/Net-SSLeay" shows that the tests that failed previously now pass; the output from emerge is attached. I've now merged the branch above into master [2]. This will be part of developer version 1.86_10 (which I'll release today), and stable version 1.86 (which we'll release soon). [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-perl/Net-SSLeay/Net-SSLeay-1.850.0.ebuild [2] https://github.com/radiator-software/p5-net-ssleay/pull/133

Subject:

emerge.txt

Message body is not shown because it is too large.

Sat May 04 12:13:28 2019 chrisn [...] cpan.org - Status changed from 'open' to 'patched'

Sun May 05 02:12:40 2019 chrisn [...] cpan.org - Status changed from 'patched' to 'resolved'

Sun May 05 02:12:40 2019 chrisn [...] cpan.org - Fixed in 1.86_10 added

Wed Jul 10 03:22:01 2019 KENTNL [...] cpan.org - Correspondence added

On 2019-05-05 04:13:27, CHRISN wrote:

Sorry for the slow reply.

It turns out I had some local settings that conspired to make this work, namely in /etc/hosts and /etc/nsswitch.conf stuff in conjunction with some terrible horrors from accidentally having systemd somewhere.

For whatever reason, on some systems the recommendation is *not* to have a localhost entry in /etc/hosts, and instead use an entry in nsswitch.conf for hosts of "files myhostname dns", and it seems that unless its an exclusive-or combination, you'll have problems.

So if you accidentally transition from one to the other, it breaks silently, but oddly, only in sandboxes.

In short, I managed to locally reduce my incidences of this problem by fixing /etc/hosts , but I'd still think being able to not barf when /etc/hosts is misconfigured might be a "feature", after all, the point of tests is to make sure the code works, not tell you your system is broken. If various system configurations can affect code execution, testing for that scenario and skipping the test might be preferred.

So, back on the subject:

I don't think a simple transition from localhost to an explicit IP is the right move, mostly because I suspect are hosts out there where IPv4 on loopback might be disabled. And even without that, I'm not sure what the guarantees are about usable IP addresses on local loopback are. I know in general you can assume most people will have a sensible setup, I'm just worried about the more esoteric builds ( which may be more common and less esoteric than we realize )

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Wed Jul 10 03:33:31 2019 KENTNL [...] cpan.org - Correspondence added

After testing the new version, the good news:

I can't make it fail on these tests

The bad news:

I can no longer make the old version fail its tests either.

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Wed Jul 10 03:42:09 2019 KENTNL [...] cpan.org - Correspondence added

A figured out what I was doing wrong to make the tests pass... Ok, so to reproduce the problem on <=1.85 on Gentoo, I need to:

* ensure no mapping for "127.0.0.1" from "localhost" in /etc/hosts
* make sure you comment out the lines in the 1.850.0 ebuild that kill the t/local tests
* emerge with FEATURES="network-sandbox"

And I have now confirmed (apparently) that under those same conditions, 1.88 does _not_ fail :)

--
- CPAN kentnl@cpan.org
- Gentoo Perl Maintainer kentnl@gentoo.org ( perl@gentoo.org )

Sat Jul 13 06:36:03 2019 chrisn [...] cpan.org - Correspondence added

Glad to hear it works for you now, Kent. On Wed Jul 10 08:22:01 2019, KENTNL wrote: Show quoted text

> I don't think a simple transition from localhost to an explicit IP is > the right > move, mostly because I suspect are hosts out there where IPv4 on > loopback might > be disabled. And even without that, I'm not sure what the guarantees > are about > usable IP addresses on local loopback are. I know in general you can > assume > most people will have a sensible setup, I'm just worried about the > more > esoteric builds ( which may be more common and less esoteric than we > realize )

I'm not sure if there's an alternative to this that'll work everywhere. Probably best to cross that bridge if we get to it. :)

Bug #128207 for Net-SSLeay: Fails t/local/06_tcpecho.t and t/local/07_sslecho.t under network sandbox