This allows re-connecting to a new session in a disconnect listener and
continue listening without having to return from listen(). The exception
can also be used to stop listening after some condition (e.g. to wait
until a specific SA got created and then stop).
The Homebrew formula has been using OpenSSL 3 for a while. The eap-peap
and pkcs11 plugins also have been enabled in the formula. The dhcp plugin
is enabled to test the port (the farp plugin was already enabled since
its port to FreeBSD/macOS). The drbg plugin is enabled to run the ML-KEM
test vectors.
While macos-13 was running on Intel, both macos-latest (macOS 15) and
macos-14 run on ARM64. While there are Intel-based images for 14 and 15,
they will only be available until August 2027 (and there aren't any Intel
devices anymore anyway).
This fixes GUI-related compatibility issues with Android 16 and allows
(pre-)selecting on-device certificates/keys with managed profiles. Also
fixes a typo in the managed config description that prevented
split-tunneling settings from working.
This allows associating a pre-installed certificate/key with a VPN
profile. For instance, one locally generated on the device via
SCEP/ETS by the MDM. It only works if the app is granted access to the
certificate/key (alias) by the MDM.
For now, users may still select a different certificate if one is
available (since this requires the certificate to be installed as
user-selectable there might not be).
Seems to not get pulled in automatically anymore. This has actually been
deprecated for years apparently. Unfortunately, it's not that easy to
replace, so keep it for now.
When targeting Android 15, edge-to-edge is the default and when targeting
Android 16, apps can't opt-out from this anymore. So we update our views
and enable edge-to-edge also for older versions (avoids the black bar
behind the system UI at the bottom). For most views we just use automatic
margins via android:fitsSystemWindows (or programmatically via
setDecorFitsSystemWindows). However, for the profile lists and log views,
we take some extra measures that allow the lists to go behind the bottom
system UI. Appropriate padding is applied at the bottom of the lists so
the last item(s) can be scrolled into full view.
No part of IKE/IPsec or X.509 uses MD2 anymore, so there really is no
reason to still support it (unlike MD4 that is used in EAP-MSCHAPv2,
MD5 that's used in EAP-MD5, or SHA-1 that's used for e.g. NAT-D hashes).
It caused test vectors to fail on systems where OpenSSL is built with
MD2 support but has it disabled at runtime.
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.
apt-key add is deprecated (and not available in trixie) as it makes the
available for all sources. The recommended approach makes the key very
specifically available for just our repository.
Debian trixie doesn't provide a 99-sysctl.conf symlink in that directory
anymore. The memory settings are also useful there as the default of
one changed and overbooking helps when forking a process with large
memory footprint (e.g. the IKE daemon).
While host_create_from_string_and_family() usually replaces %any*
keywords, this fails if the address family doesn't match (e.g. %any4 with
AF_INET6). There is no point in trying to resolve these keywords via
DNS as % is no valid character for host names.
Closesstrongswan/strongswan#2880
This adds a symbol with the current version number to all existing
plugins (the PLUGIN_DEFINE() macro makes this easy). The version is
checked when a plugin is loaded from a file in order to prevent loading
old plugins from any previous build, which could cause all sorts of
issues.
References strongswan/strongswan#2835
This prevents loading plugins from older builds that can cause all sorts
of issues as they might access struct members in different locations.
We don't check the version for statically linked plugins.
When built with static plugins and constructors, we might still want to
be able to load external plugins.
Fixes: d860c26e95 ("plugin-loader: Properly support compilation without dlopen()/dlsym() etc.")
If an uncompressed point is already unwrapped (incorrect but some tokens/
modules do this) and therefore still looks like an ASN.1 octet string,
there could be false positives with the previous checks that lead to
mangled points.
By ensuring that we unwrapped the complete ASN.1 chunk, we can already
reduce the false positive rate when the assumed length is smaller than
the chunk, which we previously accepted but isn't the case in correctly
encoded points.
And while we already checked that the first byte indicates a valid point
type/encoding, there could still be false positives. We can avoid those
with some checks on the length of the unwrapped point. In particular,
enforcing a multiple of 4/8 should fail for valid unwrapped points where
three bytes were removed in the process (ASN.1 tag and length, point
encoding).
Closesstrongswan/strongswan#2872
If an entry is added while we wait for a checked out SA in flush() (e.g.
due to an action performed by that SA), new entries might get inserted
before the one we wait for. If that was the first entry in the row, we
didn't correctly update the table and the new entries were basically lost
by overwriting the first entry in the row. As the SA count was still
increased but the new entries couldn't get enumerated, the daemon wasn't
terminated properly but was stuck in the loop in flush().
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).
This will allow us to compare new library versions against previous ones,
so we don't suddenly loose some algorithms like it happened with KDFs
recently after updating OpenSSL to 3.5.1.
If a unit test times out while generating a private key (e.g. because of
a lack of entropy), this avoids a deadlock by still releasing the read
lock that'd prevent acquiring the write lock when plugins are unloaded.
Closesstrongswan/strongswan#2850
Was apparently forgotten when support was added to the attr plugin
with 98a3ba8a5a ("attr: Add p-cscf keyword for P-CSCF server addresses").
For consistency, using an underscore like the `split*` options and not a
dash like in the attr plugin.
References strongswan/strongswan#2396
Apparently, some clients (e.g. native Android) just send an empty
EAP-Identity response. We silently ignored that previously and then
used the IKE identity for the actual EAP method. This change tries to
do something similar (i.e. don't fail if the response is empty), but by
assuming the IKE identity as EAP-Identity, we match that and possibly
can switch configs.
Closesstrongswan/strongswan#2833
Fixes: 2f2e4abe3c ("ikev2: Add support to switch peer configs based on EAP-Identities")
Use watcher and non-blocking I/O for client connections to avoid issues
with clients that stay connected for a long time.
Closesstrongswan/strongswan#2827
This now adds some state (basically a message buffer), but simplifies
error handling as we don't have to handle two potential failure paths
and could avoid some potential issues by still calling the blocking
read_all().
It also fixes a memory leak when clients disconnect.
With a long delay, the retransmit might not get sent before further tests
are evaluated on faster machines, while more retransmits should still allow
the scenario to succeed on slower ones.
Setting the salt to NULL now fails, so we set it to hash length's zeroes,
which is the default value for HKDF-Extract if no salt is passed.
Fixesstrongswan/strongswan#2828
Tobias Brunner