Clean up leak-detective whitelist for newer Botan versions but add
`botan_private_key_load` as `botan_privkey_load*` won't show up anymore
without bfd-backtraces due to inlining if we don't call it directly.
Ref: https://github.com/randombit/botan/discussions/4868
Also remove the --enable-md4 option. We never supported MD4 via wolfSSL,
as it's not available via the hash API we use (would require explicit
MD4-specific functions and structures).
Update revision for some dependency updates. While python3-setuptools is
installed on the system, the venv apparently can't use it. legacy-cgi is
required to use that old Django version with newer Python releases.
The API for libgmpada has change with 1.6 in a way that's not
backwards-compatible. So we use a different revision that includes
the required changes depending on the Debian version.
This also adds support for esa_select(), to support seamless rekeyings,
which requires updating xfrm-ada as well.
We keep MD5 enabled for now as we need it for TLS 1.0/1.1. Once we
remove that we can reconsider (although, it's also needed for EAP-MD5
and since MD4 is disabled as well, which means EAP-MSCHAPv2 won't
be available, we'd be left with only EAP-GTC for simple username/password
authentication, which nobody else supports).
The all-zero Ed25519 public key is rejected by botan_pubkey_check_key()
when the key is loaded.
Note that Botan 3 requires GCC 11 or CLANG 14, i.e. can't easily be built
on Debian bullseye or Ubuntu 20.04.
The thread-local storage function gets flagged via various botan FFI
functions when using Botan 3, whitelist that instead of all of them.
System-wide installation via pip isn't easily possible anymore on Debian
bookworm, so just use the Debian package for this (is available in old
releases as well).
The `--enable-heapmath` configure option has been deprecated. As
already described in eae30af029 ("Use wolfSSL 5.4.0 for tests"), the
alternative is to configure `--with-max-rsa-bits=8192` instead in order
to test the modp6144 and modp8192 DH groups.
With version 60.0.0 setuptools changed to a local installation of
distutils. This seems to break the installation of swid-generator (causing
an `importlib.metadata.PackageNotFoundError: swid-generator` error).
Note that while Debian ships setuptools 52.0.0, `python-daemon` recently
added a dependency on `setuptools>=62.4.0`, which installs that version
that's then later used to install swid-generator.
The main difference seems to be that the local version installs the
package in `/usr/lib/python3.9/site-packages`, while the stdlib version
does so in `/usr/local/lib/python3.9/dist-packages` (similarly for the
`swid_generator` script and the `distro` dependency).
Not sure if there is a better/proper way to fix this. Might just be an
issue with Debian bullseye and mixing system packages with those installed
via pip3.
The 5.4.0 update changed the default bignum implementation to what
could explicitly be enabled via `--enable-sp-math-all`. Since this uses
fixed-sized buffers sufficient for key sizes of SP_INT_BITS, with a default
of 4096, modp6144 and modp8192 didn't work anymore (wc_DhGenerateKeyPair()
returned MP_EXPTMOD_E). So we have to adapt the feature checks for this.
To support the larger DH groups we can either increase the buffer size
via `--with-max-rsa-bits` or add `--enable-heapmath` so buffers get
(re-)allocated as needed. We go with the latter for now.
Tobias Brunner