Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150111205842.GA2750@openwall.com>
Date: Sun, 11 Jan 2015 23:58:42 +0300
From: Solar Designer <solar@...nwall.com>
To: owl-dev@...ts.openwall.com
Subject: libnss tests

Galaxy,

libnss in Owl-current has problematic self-tests (or maybe they also
detect a real problem).

When building this package with tests enabled, it fails to build on
x86_64 after about 2 minutes with:

./all.sh: Testing Initialization ===============================
./all.sh: Exit: Checking for build - FAILED
./all.sh: #1: Checking for build - FAILED

On i686, it gets farther (and there's no "Testing Initialization" in the
log), but then it brings up an HTTP server on INADDR_ANY 9073/tcp and
seemingly with no access restrictions (a security risk for the build
machine) and starts sending plenty of requests there.  After a long
while, a process locks up, which looks something like:

  PID TTY      STAT   TIME COMMAND
 3627 pts/1    S+     0:02 /bin/bash ./all.sh
 7480 pts/1    Sl+    0:00 /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/dist/Linux2.6_x86_glibc_PTH_OPT.OBJ/bin/httpserv -D -p 9073 -A OCSPRoot -C /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/OCSPRoot.crl -A OCSPCA1 -C /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/OCSPCA1.crl -A OCSPCA2 -C /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/OCSPCA2.crl -A OCSPCA3 -C /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/OCSPCA3.crl -O random -d /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/ServerDB/ -f /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/chains/OCSPD/ServerDB/dbpasswd -i /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/aiahttp/http_pid.28080
14174 pts/1    S      0:00 -bash
20254 pts/1    S+     0:00 /usr/bin/time /usr/bin/i386 rpmbuild -bb libnss.spec --target i686-unknown-linux --define distribution Openwall GNU/*/Linux --define vendor Openwall --define buildarch i686 --define buildhost i386-40.pvt.openwall.com --define home /usr/src/world --define number 4
20255 pts/1    S+     0:00 rpmbuild -bb libnss.spec --target i686-unknown-linux --define distribution Openwall GNU/*/Linux --define vendor Openwall --define buildarch i686 --define buildhost i386-40.pvt.openwall.com --define home /usr/src/world --define number 4
23881 pts/1    S+     0:00 make
23885 pts/1    S+     0:00 /bin/bash native/Owl/build/buildworld.sh
23931 pts/1    S+     0:00 /bin/bash native/Owl/build/buildworld.sh
23963 pts/1    S+     0:00 /bin/bash native/Owl/build/buildworld.sh
24095 pts/2    S      0:00 -bash
28006 pts/1    D+     0:00 /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/dist/Linux2.6_x86_glibc_PTH_OPT.OBJ/bin/certutil -s CN=Navy ROOT CA, O=Navy, C=US -S -n Navy -t CTu,CTu,CTu -v 600 -x -d NavyDB -1 -2 -5 -f NavyDB/dbpasswd -z /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/sharedb/tests_noise -m 111053352
28007 pts/2    R+     0:00 ps xwwwww
28038 pts/1    S+     0:00 /bin/sh -e /usr/src/world/tmp-work/rpm-tmp.Kj06vk
28080 pts/1    S+     0:00 /bin/bash ./all.sh
28252 pts/1    S+     0:00 /bin/bash ./all.sh
28255 pts/1    S+     0:02 tee -a /usr/src/world/rpm-work-4/BUILD/nss-3.16.1/tests_results/security/localhost.1/output.log

Killing some processes makes the build continue, but indeed it
eventually fails because of failed tests:

Tests summary:
--------------
Passed:             13017
Failed:             9
Failed with core:   0
Unknown status:     0

[...]

1463.87user 784.19system 59:17.77elapsed 63%CPU

I'll build/release this package with RUN_TESTS=no in buildworld.conf
now (I had RUN_TESTS=no during my earlier builds anyway, to get the
binaries to a stable state with several rebuilds quicker), but you'll
need to deal with these issues somehow.  Perhaps just disable their
tests by default, unless they have some more reliable, safer, and
quicker tests?  To remind you, our RUN_TESTS is a tri-state, where the
default is package-specific.  We can have this package's tests enabled
only with explicit RUN_TESTS=yes, although even in that case we'd need
to document the security risk somewhere.

Alexander

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.