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.
Both variables `inbound_installed` and `outbound_state` are used in
`child_sa_t::destroy()` to determine whether inbound and outbound state
have to be deleted. They are assigned prior to the call to
`kernel_interface_t::add_sa()`. As this call may fail, the destructor may
try to delete a state which it has not been added.
By making the assignment of these variables dependent on the success of
the state addition, we can make sure, a `child_sa_t::destroy()` only
deletes states it has added.
Also removed the redundant checks for `my_spi` and `other_spi` being set
along with the check for the above flags. It seems that when the flags
are set, the SPIs *must* be set.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
If the lifetime of an issuing or sub CA is twice the lifetime of
the end entity certificates issued by it and the renewal cycle of
the issuing CAs is a little shorter than the validity of the end
entity certificates then three generations of CA certificates have
to be handled by the cert-enroll scripts.
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
