This currently only covers Ed25519 using the c2sp-testvectors package
and checks that our Ed25519 implementation behaves as expected from a
"ref10" implementation.
This test has Go and c2sp-testvectors as a hard dependency. It will
optionally pick up any OpenSSL package installed on the system and
test that as well.
https://github.com/C2SP/CCTVhttps://github.com/C2SP/CCTV/tree/main/ed25519
A few years back beck introduced REGRESS_SKIP_SLOW dances with the idea
that this should speed up the interop tests for us devs because this also
checked interop between opensslX and opensslY, which we don't particularly
care about. This never really worked. On a mac m1 mini the result is this:
REGRESS_SKIP_SLOW unset
9m56.69s real 3m42.24s user 3m00.70s system
REGRESS_SKIP_SLOW=yes
11m04.61s real 7m29.61s user 1m40.29s system
The problem is that REGRESS_SKIP_SLOW simply wasn't designed to handle
the huge number of tests we have here. There are many nested .for loops
resulting in several thousand tests. Each test has a name of length ~80.
REGRESS_SKIP_SLOW concatenates them into a several hundred kilobytes
long string in REGRESS_SKIP_TARGETS, iterates over all regress targets and
tests with ".if ${REGRESS_SKIP_TARGETS:M${RT}}" if it should skip them.
This means that during a regress run, make spends a lot of time linearly
scanning a huge string.
I ran into this when I added OpenSSL 3.0 tests to the already existing
1.0.2 and 1.1 tests with the result that with REGRESS_SLOW_TARGTS set
it took the better part of an hour while without it it took about 15 min.
The hack here is simply to avoid using REGRESS_SLOW_TARGTES here and
handle the situation differently.
patch, REGRESS_SKIP_SLOW=yes
5m42.32s real 2m09.98s user 1m45.21s system
The real solution would be to fix this in bsd.regress.mk, which someone
who understands make well is very welcome to do. For now, I'm happy with
this.
Debugged with jsing a few months ago
While base bc is great, it uses libcrypto's BIGNUM implementation.
This implies that the independent verification of the bn_test isn't
as independent as it should be.
With this commit, run-bc picks up bn-gh if it is installed. This appears
to work on amd64, arm64 and sparc64 (where gbc is busted). I will send
PRs to the regress maintainers once I will have tested this a bit more
thoroughly. Committing this early since I juggle way too many diffs
already.
This tests the external API, so it should not have visibility to the
inside. Silences two warnings since EC_{GROUP,POINT}_clear_free() are
now wrapped in #ifndef LIBRESSL_INTERNAL.
We can use the undocumented functions {i2s,s2i}_ASN1_INTEGER(3) to
exercise bn_to_string(). This way we use public API and remove the
need of linking statically.
Now symlinking an executable away from the rest of its installation
tree no longer prevents it from finding the libraries. This matches
the behavior of other OS linkers. Prompted by a behavior change in
lang/ghc test suite.
Swapped the order of dirname/realpath in _dl_origin_path.
Added some regress tests that pass and then bin3 that fails without
this change and reflects the behavior needd for lang/ghc.
Suggestion by semarie@, OK deraadt@
