There was an issue with OPENSSL_armcap_P in Android's static build for
OpenSSL 3.1.1+. This was finally fixed with this release (and was also
backported to older versions).
Unspecified settings should be set to null, while some MDMs might send
them as empty strings, which could cause issues (like an empty password
or trying to parse an empty DNS server address).
This can happen with empty strings, which might be set for managed
profiles, which caused the refcounting to be askew and the resolver not
to work after connecting once because it was flushed and disabled.
This fixes a regression introduced with pf_handler_t in 5.9.14. It also
binds the packet sockets correctly to the configured interface, and adds
an option for the dhcp plugin that allows binding the send and receive
sockets to different interfaces.
This can be useful if the DHCP server runs on the same server. On Linux,
the response is then sent via `lo`, so packets won't be received if both
sockets are bound to e.g. a bridge interface.
In some setups the responses from the DHCP server are sent via lo, which
does not have an address of type `ARPHRD_ETHER` (the address length is
the same, though, just all zeros, by default). Note that the dhcp plugin
doesn't actually care for the MAC address or interface details, that's
only used by the farp plugin.
Fixes: 187c72d1af ("dhcp: Port the plugin to FreeBSD/macOS")
When serving as a responder and receiving an INFORMATIONAL exchange
containing INVALID_SYNTAX after IKE_AUTH, the IKE_SA should be deleted.
Currently, it only gets deleted after receiving AUTHENTICATION_FAILED.
RFC7296 section 2.21.2 says:
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a Delete payload.
Closesstrongswan/strongswan#2636
This avoids the following warning/error:
tnc_imv_manager.c:244:39: error: passing arguments to 'tnc_imv_recommendations_create' without a prototype is deprecated in all versions of C and is not supported in C23 [-Werror,-Wdeprecated-non-prototype]
244 | return tnc_imv_recommendations_create(this->imvs);
| ^
Useless and causes a compiler warning/error:
error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C23, conflicting with a subsequent declaration [-Werror,-Wdeprecated-non-prototype]
The lines in the gperf-generated proposal_keywords_static.c are now
mapped to the (much shorter) .txt source file, which causes mismatches
like these:
genhtml: ERROR: no data for line:190, TLA:GNC, file:/home/runner/work/strongswan/strongswan/src/libstrongswan/crypto/proposal/proposal_keywords_static.txt
We could ignore "unmapped" errors in genhtml, but since the file is
generated anyway, we can also exclude it from the results and still
get such errors in case this happens for other files. Another alternative
would be to remove the `#line` macros in the generated file. Then the
coverage of the actual C file would get reported (but again, it's
generated, so there isn't much value in it).
Also updated the branch coverage option as the one with `lcov_` prefix
is deprecated.
On Ubuntu 24.04, llvm-symbolizer-18, which is used to resolve symbols
in backtraces, links libcurl.so.4 for some reason. And that in turn
requires SRP. If our custom build doesn't provide it, we get stuff
like this
/usr/bin/llvm-symbolizer-18: symbol lookup error: /lib/x86_64-linux-gnu/libcurl.so.4: undefined symbol: SSL_CTX_set_srp_password, version OPENSSL_3.0.0
and the symbols are not resolved and can't be whitelisted.
This also makes sure ASan is actually disabled if our own leak-detective
is used.
Tobias Brunner