The protocol has long been replaced by IKEv2 and is officially deprecated
since several years (RFC 9395). As a first step to removing support for
it completely, this makes the configure option disabled by default and
warns users about its use.
There is no reason to keep this around anymore (has been superseded by
TNCCS-2.0 a long time ago). Removed the corresponding test scenarios.
Since this is the last user of libxml, also removed those references.
This was primarily used in our labs to visualize some TNC aspects but
the third-party daemon and frontend we used have not seen any development
in a decade. There never was any industry interest in this protocol
anyway, so just remove it.
This has not seen any significant changes for years. So it lacks support
for modern algorithms and would require quite some work for an overhaul.
Given that we support several other crypto backends, let's just remove
this to reduce the maintenance burden.
The test scenarios and other references are also removed.
The 7.2 kernel has officially deprecated the interface and it will soon
be removed (support for hardware crypto offload has already been removed).
Also removed the corresponding test scenarios.
There is no reason to use Blowfish nowadays. Given that there are some
other plugins that still provide it, there is especially no reason to
maintain this custom implementation. Also removed the two test scenarios
that used the plugin to avoid promoting the use of this algorithm.
This was from a student project that has never been developed further.
And similar to the manager web application it lacks all sorts of modern
standards. So just remove it and the two plugins it relied on.
The test scenario is renamed to avoid confusion (neither of the two
p2pnat scenarios uses medsrv/medcli).
This fixes handling of SIGINT (CTRL+C) so we don't continue with the
next potentially hanging command (e.g. several pings after another that
fail because a required SA didn't come up correctly). We try to kill
the PID for every SIGINT in case the first one arrived before the
subshell was started. The `TDUP_<host>` variables are not updated in
the main shell when `stop_tcpdump` is called from the subshell, so
it is called redundantly during the cleanup (removed the useless guard
there and use pkill to suppress any messages if no process is found).
If we get interrupted during one of the init/cleanup WAIT_FOR waits,
we just let them running in the background when exiting the script.
They should generally not do any harm (and be terminated once the next
run is attempted, which might require a rebuild during development
anyway).
Since a103f3a284 ("testing: Add options to only run pre- or posttest
scripts of a scenario") we can now also skip the remaining steps easily.
However, we do run the posttest script to clean up properly (e.g.
terminate the daemons, restore firewall rules etc.). That's also why
it's not running in a subshell.
This reverts commit b998695344.
Seems like this is not necessary anymore. Possibly because of
8ff3238027 ("openssl: Prevent OpenSSL from using posix_memalign() if
LD is enabled").
This doesn't really seem useful (perhaps it was before we started to
configure the outbound interface on our routes). And it can actually
cause the route installation to fail e.g. for routes over point-to-point
interfaces where we'd get "Error: Nexthop has invalid gateway" errors.
Note that we can't return NULL if we find an interface as e.g. the updown
plugin uses this method to determine the outbound interface (it ignores
the nexthop), which it passes to the script. If we returned NULL, it
would pass "unknown" instead, which would cause the firewall rules to
mismatch. While it seems that 0.0.0.0/:: is ignored as nexthop by the
kernel on the installed route, I still explicitly ignore such addresses
to avoid any unintended side-effects.
The automatic route installation in the ikev2/shunt-manual-prio scenario
had to be disabled on the clients. The reason is that the route in table
220 won't have a nexthop set (the peers are directly connected), so when
trying to reach alice or venus via SSH, which matches the port-specific
bypass policies for which we don't install throw routes, the hosts will
do ARP requests for the target IPs instead of routing the packets via
moon.
Closesstrongswan/strongswan#2548
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
This ensures that packets on sun are processed on a particular CPU and
not randomly on one, which causes expected SAs not to get created or
other weird things.
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).
Seems that there is a delay before the disk can be used when using newer
QEMU versions (e.g. on Debian trixie). We get errors like these:
sfdisk: cannot open /dev/nbd0: Inappropriate ioctl for device
or
mount: /srv/strongswan-testing/build/loop: special device /dev/nbd0p1 does not exist.
A sleep before the next command seems to help.
Also see [1].
[1] https://gitlab.com/qemu-project/qemu/-/issues/1413
This new option allows to disable leak detective to reduce the runtime
during development. Either only for the command line (swanctl, pki etc.)
or optionally also for the daemon(s).
Disabling leak detective only for the CLI tools already brings a
considerable reduction in runtime (from 48m to 38m on my dev host) as
there are many such calls in the post-test stage. Any leaks in those
tools are also a lot less of an issue than leaks in the daemon. So using
this during development should be fine as long as a full test run is done
regularly (in particular before releases). Disabling leak detective
completely further reduces the runtime (to 30m on my dev host). But that
should probably only be used for functional regression tests after
verifying new code didn't introduce new leaks.
This also fixes the service script which is used for charon-tkm since
16fcdb460a ("charon-tkm: Don't use starter/stroke with charon-tkm anymore").
While some increase was necessary anyway because the idle system requires
about 5-10 MiB more memory, the main issue is resolving the code line and
function name in case of a memory leak. Calling addr2line requires a lot
more memory than before. Using backtraces via libbfd doesn't help either
because the trigger is the bfd_find_nearest_line() call we use as well.
And because we'd try to resolve all symbols that way (for whitelisting),
the memory overhead would be even higher and affect every shutdown, even
if no leak occurred. It also causes a significant time overhead (running
all tests took 75m instead of 48m).
I also tested switching to ASAN/LSAN. The peak memory usage is slightly
higher than when using libbfd, but enabling it also increased the runtime
overhead a lot (the daemon and swanctl both required about 10-20 MiB more
memory, not just during the shutdown).
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.
Tobias Brunner