We explicitly avoided TryAcquireSRWLockExclusive() because of crashes. This
issue was caused by a MinGW-w64 bug (mingw-w64 fix 46f77afc). Using a newer
toolchain works fine.
While try_write_lock() obviously can fail, not supporting it is not really an
option, as some algorithms depend on occasionally successful calls. Certificate
caching in the certificate manager and the cred_set cache rely on successful
try_write_lock()ing.
Otherwise fragmented CREATE_CHILD_SA exchanges won't get accepted
because they don't contain an SA payload.
It also prevents a warning when ordering payloads.
Fixes#752.
Previously we got no reference to the cached issuer certificate
before releasing the lock of the cache line, this allowed other
threads, or even the same thread if it replaces a cache line, to
destroy that issuer certificate in cache() (or flush()) before
get_ref() for the issuer certificate is finally called.
When invoking /bin/sh, its default PATH is used. On some systems, that does
not include the PATH where the ipsec script is installed, as charon is invoked
with a custom PATH. Explicitly setting the PATH of charon should fix this
case, properly invoking the (default) updown script.
Fixes#745.
This fixes some vici test cases on OS X, where the test thread tries to cancel
the watcher thread during cleanup, but fails as select() does not honor the
pre-issued cancellation request.
The IPv6 length field denotes the payload length after the 40 bytes header.
Fixes: 293515f95c ("libipsec: remove extra RFC4303 TFC padding appended to inner payload")
I came across an issue with src/libimcv/imcv.c where
IMCV_DEFAULT_POLICY_SCRIPT is hardcoded.
It fails where ipsec_script is renamed to, for example, strongswan from
default ipsec.
We assume that a responder is behind a static NAT (e.g. port forwarding)
and allow remote address updates in such situations.
The problem described in RFC 5996 is only an issue if the NAT mapping
can expire.
As we want to avoid the libstrongswan include dependencies for libvici, avoid
the use of the bool type. Unfortunately this change may break the ABI for
vici_dump(). As this function is mostly for debugging purposes, we do it
nonetheless; my apologies if somebody already relies on the ABI stability of
that function.
Martin Willi