When issuing a deregistration message, some last events may still be sent
by the daemon before deregistration completes. Ignore such event messages
silently during deregistration, avoiding exceptions like:
vici.exception.SessionException:
Unexpected response type 7, expected '5' (EVENT_CONFIRM)
The architecture of the Python client is completely blocking, which is fine
for many simple scripts. For more complex applications that do other I/O
and listen for vici events, the most feasible way to integrate the client is
to use a dedicated thread.
Unfortunately, Python has no simple support for thread cancellation. And
having that thread in a blocking recv() does not allow to terminate the
thread gracefully with an Event or the like.
As a way out, add a timeout to the listen() call, so the thread can
periodically do other things, like checking for termination Event and
react on it. Returning from listen() on timeout can be suboptimal, though,
as it involves registration/deregistration for events, including the risk
for missing events while not registered. So return a (None, None) tuple
instead on timeout, allowing the caller to periodically do other things
while staying registered for the events and continue in listen().
The timeout applies to the socket recv() for the start of the header, only,
so a message is either read in full or times out, avoiding the risk
of breaking message framing on the stream with partial reads.
Depending on the configured hard lifetime the default soft lifetime
might not make sense and could even cause rekeying to get disabled.
To avoid that, derive the soft lifetime from the hard lifetime so it's
10% higher than the soft lifetime.
References strongswan/strongswan#1414
Also avoid returning 0 and disabling rekeying in the rare case of
`jitter = rekey` and the `1/jitter` chance of that happening (returning
1 at least doesn't disable rekeying).
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#1414
The x509 plugin retrieves serial numbers with two's complement
encoding whereas the openssl plugin partially returns them without
leading zeroes.
Serial numbers in X.509 certificates, X.509 CRL, X.509 attribute
certificates, OCSP Requests and OCSP responses are now returned in
canonical form without prepended zero octets.
Ubuntu 22.04 ships OpenSSL 3, which requires debug symbols so we can
whitelist leaks because we don't deinitialize the library. And because
the shipped library is not built with `-fno-omit-frame-pointer`, the
build with AddressSanitizer can't use its fast stack unwind method.
However, the previous workaround for DTLS handling with glibc apparently
isn't necessary anymore.
In the custom OpenSSL build we drop no-stdio as that lets the configure
check for libldns fail because ERR_print_errors_fp@OPENSSL_3.0.0 is not
found.
For ccache, the default path to the cache directory has changed.
Also simplified the NM tests as there is only one build since
085daf474330 ("nm: Remove old libnm-glib compat stuff").
At least since Ubuntu 22.04 there are lots of (apparently non-fatal)
"DWARF error: could not find variable specification" errors generated
by bfd_find_nearest_line(). This also happens with addr2line, which
internally uses libbfd. No idea what the actual issue is (it still
happens with binutils 2.39 in Ubuntu 22.10), but since it doesn't seem
to affect the functionality we need this avoids filling the test logs
with useless messages.
The wolfSSL's OpenSSL compatibility layer is not used by the plugin at
all and preventing its inclusion avoids conflicts with ASN1_ constants.
The inclusion of wolfssl/ssl.h is moved to the only file that requires
it as older wolfSSL versions defined a conflicting ASN1_GENERALIZEDTIME.
Other changes address issues with the FIPS use case.
Closesstrongswan/strongswan#1332
A recent change added CALLBACK to PENUM_PAGE_FILE_CALLBACKW/A in psapi.h,
which conflicts with our own macro of the same name. Our compat/windows.h
header undefs the Windows definition, but that only works if Windows
headers are included before ours, which wasn't the case for psapi.h.
This avoids a conflicts as mysql80-client has a dependency on either
openldap24-client (FreeBSD 12) or openldap26-client (FreeBSD 13) so e.g.
installing openldap24-client on FreeBSD 13 causes
openldap26-client-2.6.3 conflicts with openldap24-client-2.4.59_4 on /usr/local/bin/ldapadd
Similarly, when installing openldap26-client on FreeBSD 12. So just let
the mysql80-client package decide which version is installed.
There are spurious crashes after test runs (during the reporting phase
of LeakSanitizer) that are triggered by seemingly unrelated code changes.
It seems to be related to how glibc handles dynamic TLS allocations.
