The `--enable-heapmath` configure option has been deprecated. As
already described in eae30af029b1 ("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.
A recent security fix for Git added a fatal error if the directory that
contains the .git directory is not owned by the user that runs git in
that directory tree:
Determine strongSwan version fatal: unsafe repository ('...' is owned by someone else)
To avoid this, we call the git commands as owner of the source
directory (the script has to run as root, so this is no problem).
The user/group ID and name is now also determined via `stat(1)` so it
directly depends on the actual source dir and should work even when not
using sudo.
The logrotate function causes the apt history to be split into
several parts at arbitrary points in time. If history.log only
is parsed then some package installation changes stored in
zipped backup history files might get lost.
Thus sw-collector now searches all backup history files until
a date older than the current event stored in the collector.db
database is found, so that no entries get overlooked.
This way we get updated versions automatically (referencing "master"
required manually deleting the downloaded archives and the unpacked
directories). It also allows switching versions when working in different
branches (note that REV can also be set to a commit ID, e.g. to test
changes before tagging them later and merging the branch).
Use the same configure options etc. for both builds (no need for the cert
options as we don't use TLS or X.509 parsing) and switch to a Git commit
that includes the SHA-3 OID fix (it's actually the fix itself).
For documentation purposes the new folders ikev1-algs, ikev2-algs,
ikev1-multi-ca and ikev2-multi-ca have been created. Most of the
test cases have now been converted to the vici interface. The
remaining legacy stroke scenarios yet to be converted have been put
into the ikev2-stroke-bye folder.
For documentation purposes some legacy stroke scenarios will be kept
in the ikev1-stroke, ikev2-stroke and ipv6-stroke folders.
To align with RFC 4519, section 2.31/32, the abbreviation for surname
is changed to "SN" that was previously used for serialNumber, which does
not have an abbreviation.
This mapping had its origins in the X.509 patch for FreeS/WAN that was
started in 2000. It was aligned with how OpenSSL did this in earlier
versions. However, there it was changed already in March 2002 (commit
ffbe98b7630d604263cfb1118c67ca2617a8e222) to make it compatible with
RFC 2256 (predecessor of RFC 4519).
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#179.
Mainly to test TKM's ability for handling multiple CAs and that the
received intermediate CA certificates are passed in the right order.
But also added a regular scenario where two intermediate CA certificates
are sent by one of the clients.
Verify certificate chains starting from the root CA certificate and
moving towards the leaf/user certificate.
Also update TKM-RPC and TKM in testing scripts to version supporting the
reworked CC handling.
