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.
Self-signed trust anchors are not part of the certificate path validation
according to RFC 8280, section 6.1:
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path.
But policies in them could still be used, as stated in section 6.2:
Where a CA distributes self-signed certificates to specify trust
anchor information, certificate extensions can be used to specify
recommended inputs to path validation. For example, a policy
constraints extension could be included in the self-signed
certificate to indicate that paths beginning with this trust anchor
should be trusted only for the specified policies. [...]
Implementations that use self-signed certificates to specify trust
anchor information are free to process or ignore such information.
So unconditionally enforcing that self-signed root certificates contain
the policies is probably too strict. Often they won't contain the
extension at all. With this change, we allow that but still enforce the
policies in case such a certificate contains them. The other
policy-related constraints are also enforced still should they be
contained.
Closesstrongswan/strongswan#2601
Some scenarios disable route installation and if they are executed before
any scenarios that don't, there won't be a rule for table 220 and we get
"FIB table does not exist" errors.
Directly calling setup.py is deprecated (apparently has been for a while,
but now we get large warnings). Direct installation is also discouraged.
So this removes that option. The built wheel (the old egg format is not
used/built anymore) can be installed manually in a venv or the like.
The previous approach had two drawbacks:
First, it caused duplicate public keys because when the `certificate_t`
object was created and added to the credential set it had no subject
assigned yet. So it defaulted to the key ID. However, all previously
loaded keys had their subject already changed to an identity, so there
never was a match and new objects were always added whenever a config
with raw public keys was loaded.
Second, the subject was replaced in a way that's not thread-safe on an
object that's already shared in the public credential set. So other
threads could potentially access the `identification_t` object that's
destroyed during that process.
References strongswan/strongswan#853Closesstrongswan/strongswan#2561
There are a lot of files without patterns and running them all through
sed is quite slow. Using grep first makes this quicker (about 0.5s per
test). Ignoring PEM files is also helpful.
In particular the swanctl calls all take a while and this allows doing
them in parallel if multiple hosts are involved. This reduces the runtime
of each test by 1-3 seconds.
These have been discouraged for a long time and there are now more and
more crypto libraries that have them disabled by default. However, for
some we only can detect this at runtime, in particular in FIPS mode, so
tests would fail as the plugins would still announce them. So instead
we just remove the schemes from these tests for now (at least for RSA,
removing signatures with SHA-1 completely isn't an option yet as that's
still the default with some clients).
Closesstrongswan/strongswan#2523
In particular for the first one randomization could trigger an additional
rekeying, which let the "Adding ESA ..." check fail. But even without
randomization (could be seen in the second scenario that already uses
`rand_time=0`) 4 seconds can apparently be too low some time.
When compiling with -O3 with GCC 14, we get the following warning/error:
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29:10: error: '__builtin_memcpy' offset [0, 3] is out of the bounds [0, 0] [-Werror=array-bounds=]
29 | return __builtin___memcpy_chk (__dest, __src, __len,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
30 | __glibc_objsize0 (__dest));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~
Which seems completely bogus as that array has a fixed size of 16 and
some weird workarounds remove the warning (e.g. adding an assignment
to `subset->netbits` before the `memcpy()`). This is also the only
place GCC complains about and we use `memcpy()` all over the place
in this file to set those addresses.
Closesstrongswan/strongswan#2509
While this does require quite a bit of memory, on initiators there are
usually fewer concurrent SAs getting created so this should be less of
an issue than on a gateway that handles lots of SAs as responder.
The speed up is about 30% on the initiator during the decapsulation,
while the key generation does take a bit more time (about 3%).
This follows FIPS 203 relatively closely but takes some ideas from the
reference implementation. In particular, how to avoid potential
side-channels via direct C division/modulo operations. However, it just
uses Barrett reduction (no Montgomery reduction) and no negative
coefficients to avoid number format conversions and keep the
implementation clearer.
If uniqueness checks are disabled and multiple IKE_SAs with the same
identities are created, an offline lease could have gotten reassigned
during a make-before-break reauthentication if such an SA was closed
earlier. Checking for an online lease for the same client (IP/port)
first ensures that the correct IP is reassigned during the
reauthentication.
References strongswan/strongswan#2472
Since we now open sockets for each address family independently (via
IPV6_V6ONLY) and without SO_REUSEADDR, it could happen with the previous
order on Linux that opening the port that was allocated as ephemeral
port for IPv6 was already used by a different process for IPv4.
Most IPv6 sockets on ephemeral ports will not have IPV6_V6ONLY set, so
the same port is also reserved for IPv4. Therefore, it's save to assume
that any ephemeral port we first get for IPv4 is free for IPv6.
References strongswan/strongswan#2494
This reverts commit 84a3077e78.
Support for dots in names of settings was removed quite a while ago and
now the \. sequence caused `SyntaxWarning: invalid escape sequence`.
The order was different when not setting `esp_proposals` or explicitly
configuring `default`.
Fixes: 33412158f5 ("ike: Send AEAD ESP default proposal first")
Similar to the previous commit. Instead of
generating rule 10 (1258)
followed by (or not if the list is empty)
generating payload of type PROPOSAL_SUBSTRUCTURE
we now get
generating rule 10 LIST of PROPOSAL_SUBSTRUCTURE
in the debug log.
Instead of this
parsing rule 10 (1258)
we now see this
parsing rule 10 LIST of PROPOSAL_SUBSTRUCTURE
in the debug log. Particularly useful if the list is empty as there won't
be a message like this following it:
x bytes left, parsing recursively PROPOSAL_SUBSTRUCTURE
struct ifreq can't be used for IPv6 as the ifr_addr member is not large
enough. Actually, configuring an IPv6 address via an AF_INET socket won't
work anyway. And unfortunately, it's not standardized how IPv6 addresses
are installed, so we have to do this quite differently on Linux and on BSD.
However, we already use SIOCAIFADDR for IPv4 on newer FreeBSD systems,
which wasn't the case when this patch was originally created in 2014.
Consider queued child-creating tasks when reloading configs that have
`start` as start action. Besides some possible corner cases it fixes
handling IKE_SAs that are current getting established and have no
established CHILD_SAs yet.
Closesstrongswan/strongswan#2418
This is particularly important for IKE_SAs that are not yet established,
which would get terminated as they have no established CHILD_SAs yet.
Fixes: 72f9a21b22 ("Merge branch 'vici-reload-actions'")
Otherwise, all configs would be considered to even some degree as the
ports usually match.
Closesstrongswan/strongswan#2441
Fixes: 9228a5109b ("ike-cfg: Consider port information in IKE config match")
This adds support for multiple key exchanges (no KEMs yet as none are
standardized so far). Work on this started over five years ago and went
through multiple iterations (first our own protocol, then standardized
extensions in different variations).
IKE_INTERMEDIATE exchanges, defined RFC 9242, are used to transport
multiple KE payloads between the IKE_SA_INIT and IKE_AUTH exchanges.
To rekey IKE and CHILD_SAs with multiple key exchanges, IKE_FOLLOWUP_KE
exchanges are used, as defined in RFC 9370.
In proposals, additional key exchange methods are configured via `keX_`
prefix, where X is a number between 1 and 7. For example, `ke1_ecp256`
adds ECP_256 as additional KE method. As with regular key exchanges,
peers have to agree on a method for each round unless no algorithms are
defined by both or `keX_none` is configured to make that round explicitly
optional.
Also changed is how rekey collisions are handled, which makes CHILD_SAs
properly trackable via child_rekey() hook.
Previously, it could happen that child_rekey() was triggered twice for
the same "old" SA. For listeners that would mean they'd loose track as
they'd be tracking a new SA that wasn't relevant anymore and for which
no updown event would ever get triggered (it was the redundant SA in a
collision). This new assert ensures that events are triggered in a
predictable way and listeners can track SAs properly.
As the winner of a rekey collision, we previously always triggered the
child_rekey() event once when creating the redundant SA on behalf of the
peer in the passive child-rekey task and then a second time when
creating the winning SA in the active task. However, both calls passed
the replaced CHILD_SA as "old". This made tracking CHILD_SAs impossible
because there was no transition from the redundant, "new" SA of the
first event to the "new", winning SA of the second. Of course, when the
second event was triggered, the redundant SA might not have existed
anymore because the peer is expected to delete it, which could happen
before the CREATE_CHILD_SA response arrives at the initiator.
This refactoring ensures that the child_rekey() event is triggered in
a way that makes the CHILD_SAs trackable in all reasonable (and even
some unreasonable) scenarios. The event is generally only triggered
once after installing the outbound SA for the new/winning CHILD_SA.
This can be when processing the CREATE_CHILD_SA in the active child-rekey
task, or when processing the DELETE for the old SA in a passive
child-delete task. There are some cases where the event is still
triggered twice, but it is now ensured that listeners can properly
transition to the winning SA.
Some corner cases are now also handled correctly, e.g. if a responder's
DELETE for the new CHILD_SA arrives before its CREATE_CHILD_SA response
that actually creates it on the initiator. Also handled properly are
responders of rekeyings that incorrectly send a DELETE for the old
CHILD_SA (previously this caused both, the new and the old SA, to get
deleted).
Tobias Brunner