The first step in all existing setup.sh scripts is to call clean.sh. To
reduce code duplication and ensure all system tests added in the future
behave consistently with existing ones, invoke clean.sh from run.sh
before calling setup.sh.
(cherry picked from commit d8905b7a9c)
When trying to extract the key ID from a key file name, some test code
incorrectly attempts to strip all leading zeros. This breaks tests when
keys with ID 0 are generated. Add a new helper shell function,
keyfile_to_key_id(), which properly handles keys with ID 0 and use it in
test code whenever a key ID needs to be extracted from a key file name.
(cherry picked from commit 7d6eaad1bd)
For all system tests utilizing named instances, call clean.sh from each
test's setup.sh script in a consistent way to make sure running the same
system test multiple times using run.sh does not trigger false positives
caused by stale files created by previous runs.
Ideally we would just call clean.sh from run.sh, but that would break
some quirky system tests like "rpz" or "rpzrecurse" and being consistent
for the time being does not hurt.
(cherry picked from commit a077a3ae8a)
$RANDFILE, i.e. bin/tests/system/random.data, should only be written to
if a system test requires support for cryptography and that file does
not already exist. Otherwise, when multiple system tests are run in
parallel, that file might get truncated due to bin/tools/genrandom.c
using fopen() with mode "w" when writing the destination file. With
unfortunate timing, this may cause system tests employing BIND tools
which need entropy (e.g. dnssec-keygen) to fail.
Make sure bin/tests/system/metadata/tests.sh no longer calls
bin/tools/genrandom since $RANDFILE is guaranteed to already be created
by the time bin/tools/genrandom is currently called because
bin/tests/system/metadata/prereq.sh uses bin/tests/system/testcrypto.sh.
Make sure bin/tests/system/sfcache/prereq.sh only writes to $RANDFILE if
it does not already exist.
(cherry picked from commit c12388f5e8)
4686. [bug] dnssec-settime -p could print a bogus warning about
key deletion scheduled before its inactivation when a
key had an inactivation date set but no deletion date
set. [RT #45807]
(cherry picked from commit 330365566d)
4685. [bug] dnssec-settime incorrectly calculated publication and
activation dates for a successor key. [RT #45806]
(cherry picked from commit 5201b96d03)
Conflicts:
bin/tests/system/conf.sh.in
lib/dns/win32/libdns.def.in
lib/isc/win32/file.c
The merge also needed to update files in legacy and tcp system tests
(newly introduced in master after branch was created) to introduce use
of lockfile.
3730. [cleanup] Added "never" as a synonym for "none" when
configuring key event dates in the dnssec tools.
[RT #35277]
3729. [bug] dnssec-kegeyn could set the publication date
incorrectly when only the activation date was
specified on the command line. [RT #35278]
3705. [func] "configure --enable-native-pkcs11" enables BIND
to use the PKCS#11 API for all cryptographic
functions, so that it can drive a hardware service
module directly without the need to use a modified
OpenSSL as intermediary (so long as the HSM's vendor
provides a complete-enough implementation of the
PKCS#11 interface). This has been tested successfully
with the Thales nShield HSM and with SoftHSMv2 from
the OpenDNSSEC project. [RT #29031]
of DNSSEC data in dig output and in generated
zone files:
- DNSKEY record comments are more verbose, no
longer used in multiline mode only
- multiline RRSIG records reformatted
- multiline output mode for NSEC3PARAM records
- "dig +norrcomments" suppresses DNSKEY comments
- "dig +split=X" breaks hex/base64 records into
fields of width X; "dig +nosplit" disables this.
[RT #22820]