nm: Don't set DL_LIBS to 'none required' in configure script

This copies the AC_SEARCH_LIBS check from the main strongSwan
configure.ac.

When building networkmanager-strongswan with slibtool if fails.

  ld: cannot find none: No such file or directory
  ld: cannot find required: No such file or directory

This is because configure.ac uses AC_SEARCH_LIBS to find dlopen which
sets the value of $ac_cv_search_dlopen to 'none required' which then
gets set in DL_LIBS and passed to slibtool.

With GNU libtool it silently ignores the unknown arguments.

Gentoo issue: https://bugs.gentoo.org/914100

Closes strongswan/strongswan#2141

Signed-off-by: orbea <orbea@riseup.net>

Merge branch 'android-http-proxy'

Adds support for HTTP proxy server.

Closes strongswan/strongswan#2789

android: New release after adding HTTP proxy configuration

android: Apply proxy server setting when creating TUN device

This is only available with Android 10+ (SDK 29+).

android: Avoid proxy settings in the internal fetcher

android: Allow setting proxy settings in managed profiles

android: Import proxy server settings

android: Make proxy server configurable

android: Add properties to VPN profiles for proxy server configuration

android: Don't mention IKEv1 and L2TP in app description

Also removed on Play so the app does not show up when people search
for these keywords (they tend to not read the actual description and
then are surprised that neither protocol is supported).

android: Update dependencies

identification: Clarify that ID_USER_FQDN is just an alias for ID_RFC822_ADDR

This means userfqdn: is a valid prefix for regular expressions.

swanctl: Document that IP-TFS mode is subject to mode negotiation

testing: Make sure ML-KEM scenarios use our ml plugin

We now support OpenSSL's implementation in the openssl plugin.  This
makes sure our plugin is used on at least one of the hosts if we ever
switch to an OpenSSL version that supports ML-KEM.

In the ikev2/rw-mlkem scenario the logic is reversed.  There the ml plugin
is preferred on moon to test the responder side (and carol for the
initiator) and dave will switch to OpenSSL if it ever provides ML-KEM.

Version bump to 6.0.2dr2

testing: soup plugin removed from test environment

Version bump to 6.0.2dr1

Merge branch 'libsoup3'

Ports the soup plugin to libsoup 3.

Closes strongswan/strongswan#2788

github: Use libsoup 3 for tests

Requires installing libxml2-dev explicitly for the alpine build as
libsoup-dev had a dependency on it.

leak-detective: Remove whitelisted libsoup2.x functions

As mentioned in 0f141fb095a41a9fdfe5c111269eb643dc643494, we can't
really whitelist the "leaks" in GLib, so don't even try to do anything
with libsoup3.x.

soup: Port to libsoup 3

fetcher: Remove unused FETCH_HTTP_VERSION_1_0 option

Was only used by the removed scepclient and does not serve any purpose
nowadays anyway.

unit-tests: Serial number tests depend on X.509 certificate parsing

Requires additional plugin features, but if this is available, the
others are usually as well.

wolfssl: Fix build if wolfSSL was built in OpenSSL-compat mode

Merge branch 'wolfssl-fips'

Fixes various issues when building the wolfssl plugin against wolfSSL's
FIPS module.

References strongswan/strongswan#2603
Closes strongswan/strongswan#2771

wolfssl: Unlock keys if necessary when using FIPS module

Wrap the functions that require it in PRIVATE_KEY_UNLOCK/PRIVATE_KEY_LOCK.
This can't be done at plugin initialization because it needs to be done
for every thread. strongSwan currently doesn't provide on-thread-create
callbacks for plugins so we need to wrap each direct call. Another reason
to do so is that some functions we call (e.g. wc_EccKeyToDer) internally
call PRIVATE_KEY_UNLOCK/PRIVATE_KEY_LOCK and would leave the keys locked
for that particular thread.

wolfssl: Properly initialize ECC private key object

wolfssl: Set a dummy key when testing KDF implementations

In FIPS mode, wolfSSL enforces a minimum key size for these algorithms.

test-vectors: Remove HMAC PRF test vectors with key size 4

Some implementations enforce a minimum key size (e.g. wolfSSL in FIPS
mode) and in practice, the keys will be longer anyway (e.g. our nonces
are 32 bytes).

wolfssl: Include settings.h in case WOLFSSL_USER_SETTINGS is defined

wolfssl: Use consistent defines for ECC public/private key loading

HAVE_ECC_KEY_IMPORT can be defined while HAVE_ECC_SIGN is not.
So just use the same defines we use when defining the load functions.

wolfssl: Call wc_SetSeed_Cb() as required for FIPS-mode

Merge branch 'iptfs'

This adds basic support for IP-TFS/AGGFRAG (RFC 9347).  The Linux kernel,
since 6.14, only supports aggregation/fragmentation so far.  The actual
TFS features will get added later.

testing: Add ikev2/net2net-iptfs scenario

testing: Add config for Linux 6.14

This has IP-TFS enabled.

conf: Document global IP-TFS settings

child-create: Negotiate IP-TFS mode if configured

notify-payload: Add notify type for IP-TFS/AGGFRAG

kernel-netlink: Support IPTFS mode and attributes

child-sa: Allow disabling fragmenting packets across AGGFRAG payloads

This is necessary if the peer isn't able to handle such fragments.

kernel-ipsec: Add flag to disable sending fragments across AGGFRAG payloads

We have to set this if the peer indicates that it doesn't support
handling such fragments in the notify.

vici: Make IP-TFS mode configurable

include: Add XFRM mode and attributes for IP-TFS

ipsec-types: Add new mode for IP-TFS

Added at the end as the numeric mode is e.g. used in SQL databases.

Merge branch 'per-cpu-sas'

This adds support for per-CPU SAs (RFC 9611).

testing: Add ikev2/per-cpu-sas-encap-transport scenario

Tests transport mode and UDP encapsulation with random source ports.
Interestingly, the responder always uses the same SA to respond (maybe
due to the cache on the policy).

testing: Add ikev2/per-cpu-sas-encap scenario

Basically the same as the one without UDP encapsulation, but here the
outbound SAs use random source ports.

kernel-netlink: Suppress NAT mapping updates for per-CPU SAs

As we set the remote port to 0, we'd get a mapping change message with
every packet. Setting the threshold avoids all kernel messages after the
first, which we suppress explicitly as well.

child-sa: Configure UDP encapsulation for per-CPU SAs

As the kernel does not support processing UDP-encapsulated and plain ESP
for the same SA, we require forcing UDP encapsulation if there is no NAT.

vici: Make UDP encapsulation for per-CPU SAs configurable

child-cfg: Add flag to enable UDP encapsulation for per-CPU SAs

testing: Add per-CPU SA test scenario

testing: Configure multiple virtual CPUs for moon and sun

This allows testing per-CPU SAs by e.g. pinging over a specific CPU
via taskset.

testing: Enable SMP support for latest kernels

swanctl: Report per-CPU information in --list-sas

vici: Report per-CPU SA information

vici: Make per-CPU CHILD_SAs configurable

kernel-netlink: Forward CPU ID from acquires

trap-manager: Add support to handle acquires for per-CPU SAs

kernel-handler: Log CPU ID that's passed with an acquire

kernel-interface: Optionally pass CPU ID for which an acquire was triggered

ike-sa: Accept optional CPU ID when initiating CHILD_SAs

ike-sa: Sort CHILD_SAs by CPU ID

This might make debugging easier and also ensures that a possible
fallback SA without CPU ID is established first when reestablishing
an IKE_SA.  Because even if such an SA is established first initially,
that might change later depending on when per-CPU SAs are rekeyed.

child-rekey: Maintain per-CPU values during rekeying

child-create: Add support to negotiate per-CPU SAs

updown: Don't call the script for per-CPU SAs

Rules are installed for the fallback SA that has no CPU ID assigned.

ha: Ignore per-CPU CHILD_SAs

These only work on initiators (with trap policies), which is something
the plugin doesn't support.

forecast: Ignore per-CPU CHILD_SAs

Not sure if this combination does make sense as the plugin itself would
be a major bottleneck.

Similar to the connmark plugin, PREROUTING rules list SPIs or UDP ports,
which would be necessary for all SAs while the OUTPUT rules would only be
required once.

connmark: Ignore per-CPU CHILD_SAs

The combination probably doesn't make much sense.

The OUTPUT rules would definitely only be required once, while the INPUT
and PREROUTING rules list individual SPIs and/or UDP ports, which would
be necessary for all SAs.

By the way, the rules in PREROUTING might actually not be necessary
anymore if the set_mark_in option was used for such SAs.

child-sa: Add support for per-CPU SAs

The CPU ID is also set on inbound SAs as it can be used to configure RSS
or some eBPF program.

kernel-netlink: Add support to enable per-CPU acquires on policies

kernel-netlink: Add support to set CPU ID on SA

ipsec-types: Add identifier for the maximum (=no) CPU ID

include: Add XFRM identifiers for per-CPU SAs/acquires

child-cfg: Add flag to enable per-CPU SAs

notify-payload: Add notify types for per-resource CHILD_SAs

testing: Include the kernel build number

Merge branch 'acquires-seq'

This uses the sequence number from acquires when installing the SA. This
allows handling narrowing properly by changing the reqid and still
removing the temporary state in the kernel.  It also changes that
traffic selectors are reused during rekeying/recreation/reauthentication,
so narrowed selectors won't return to the wider configured TS because
there won't be any TS from triggering packets to narrow again.

testing: Add ikev2/net2net-route-narrow scenario

child-create: Consider previous TS when checking for duplicates

child-sa: Add helper to check if a list of TS match negotiated TS

child-create: Maintain traffic selectors during rekeying/reauthentication

If we don't do this, narrowed SAs would default to the wide configured
traffic selectors and the peer won't know if/how to narrow.

child-create: Use more generic method to pass information from previous SA

Besides the previous key exchange method, this will allow us to also
reuse the previous traffic selectors.  Some data is still passed in
separate methods as some are set even when there is no previous SA and
others are not set in all cases.

The interface for queue_child() now optionally takes the previous
Child SA to handle both recreations and initiations from scratch.

child-cfg: Use traffic selector list

traffic-selector-list: Add helper class to manage a collection of TS

Provides functions to optionally resolve dynamic TS and to narrow
them based on a list of supplied TS.

trap-manager: Set seq. no. for CHILD_SAs not initiated by an acquire

This fixes cases where `start_action = trap|start` is used and an acquire
is triggered while the SA is initiated (granted if narrowing is expected,
that's not a recommended configuration as the responder can only use
the first config when there is no packet TS).  The resulting second
create-child task will potentially get dropped by the duplicate check,
so the temporary state won't get removed and traffic is blocked until
that expires, neither can acquires get triggered for traffic that doesn't
match the initial SA's policies.

child-create: Trigger CHILD_INSTALLING event after setting traffic selectors

This was the case before bce0c5fd74a0 ("child-create: Update CHILD_SA IP
addresses before installation") and allows listeners to consider the
traffic selectors of the SA that's about to get installed.

child-create: Use helper to compare packet TS against CHILD_SAs

child-sa: Add helper to check if two TS match negotiated TS

acquire-job: Use helpers to manage acquire data

kernel-listener: Add helpers to clone/destroy acquire data

child-create: Consider triggering TS when checking for duplicate

vici: Include reqid when listing trap policies

kernel-pfkey: Don't use TS from acquire in tunnel mode

The addresses are actually the endpoints of the SA, not information on
the matched packet (except that the RFC says to set the ports and
protocol of the packet in the source address, which the Linux kernel
doesn't do).  So these are useless, unless transport mode is used, where
the addresses are needed for the wildcard trap policy use case.

The RFC mentions a PROXY address (a single one, not two), that could
apparently be something like the source address in tunnel mode.
However, the description of how this is used in the RFC is quite weird
and neither Linux nor FreeBSD send such an attribute in SADB_ACQUIRE.

kernel-netlink: Add support for acquire sequence numbers

Note that while PF_KEYv2 also uses sequence numbers to identify acquires,
which we currently don't use correctly by the way, it does not include
information about the packet that triggered an acquire.  What we receive
in src and dst, and currently forward as traffic selectors, are actually
the designated endpoints of the SA. So especially in tunnel mode this is
useless to do narrowing on the responder (these addresses might not even
match the configured TS).

kernel-interface: Change reqid if seq. nos. are supported and narrowing occurred

With the sequence numbers we don't have to maintain the reqid to delete
the temporary state.

One exception is with labels.  There we currently only install trap
policies with the generic label.  SAs created from those don't have
policies installed, so we have to reuse the reqid of the trap even if
narrowing occurs.

And as before, we reuse the reqid without checking traffic selectors if
sequence numbers are not supported.

Note that if a CHILD_SA is manually initiated (i.e. has no sequence
number assigned) right before an acquire is triggered, there are several
possible outcomes depending on whether narrowing occurs.  If there is no
narrowing, the same reqid is assigned and the kernel will remove the
temporary SA when the SA is installed (no seq => reqid match).
Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire
state in the trap manager gets removed.  If there is narrowing, a new
reqid is allocated, so the installation of the SA will not remove the
temporary state.  However, due to the narrowing, the duplicate check
fails and when the duplicate is installed (with sequence number), the
temporary state is deleted (as is the state in the trap manager).

child-cfg: Use separate method to get configured traffic selectors

Optionally with "dynamic" traffic selectors resolved.  A new method
is added for those cases where we actually want to select potentially
narrowed traffic selectors using a supplied list.  The latter now also
always logs details, while the former does not.

trap-manager: Use sequence numbers to identify acquires

Either use the sequence number from the kernel (and potentially update
it if the acquire was retriggered), or generate our own sequence
numbers, which simplifies matching acquires to established/destroyed
CHILD_SAs.

ike: Support optional acquire sequence numbers when creating CHILD_SAs

child-sa: Store and propagate optional acquire sequence number