Instead of rejecting the certificate completely if a certificate has a policy
OID that is actually not allowed by the issuer CA, we accept it. However, the
certificate policy itself is still considered invalid, and is not returned
in the auth config resulting from trust chain operations.
A user must make sure to rely on the returned auth config certificate policies
instead of the policies contained in the certificate; even if the certificate
is valid, the policy OID itself in the certificate are not to be trusted
anymore.
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.
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.
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.
To use SSL in curl, we need to initialize the SSL library in a thread-safe
manner and provide the appropriate callbacks. As we already do that in our
crypto plugins using these libraries, we depend on these features.
This implies that we need the same plugin enabled (openssl, gcrypt) as the
curl backend is configured to use to fetch from HTTPS URIs.
Since 4b670a20 we require an explicit strongswan.conf to re-load configurations.
However, the define was missing in the build, breaking SIGHUP based config
reloading.
Fixes#651.
Due to the issue described in c641974, purge() inadvertently destroyed
CA certificates that should have been kept (while the pointer to these
objects remained in the array). This lead to incorrect reference counts
and after a few reauthentications with multiple authentication rounds,
which cause calls to purge(TRUE), to crashes.
Because enumerate() for value based arrays returns a pointer directly to
the internal array elements and because array_remove_at() or rather the
called array_remove() may move elements over the element at the currently
enumerated position, the pointer passed to enumerate() will point to a
different array element after the array_remove_at() call. The caller
will thus operate on the wrong element if that pointer is accessed again
before calling enumerate().
For performance reasons we currently don't change the implementation to copy
each array element during enumeration to a private member of the enumerator and
return a pointer to that. Similarly, due to the danger of subtle bugs we don't
remember the pointer passed to enumerate() to later redirect it to a copy
created during the array_remove_at() call.
In the previous implementation queued jobs could prevent a service from
getting destroyed. This could have lead to a deadlock when the
processor is cancelled. Now destroy() still blocks, but waits only for
actually running tasks. The service instance is reference counted so that
queued jobs can safely be destroyed.
Calling on_accept() sometimes lead to deadlocks when service->destroy()
was called concurrently. That is, two threads waiting in on_accept() but
the last worker would only wake one due to the call to signal(). Calling
broadcast() wouldn't help either as that could lead to crashes if the thread
that called destroy() is woken first.
This is also more efficient as a constant pool of concurrent workers can
be maintained, otherwise peaks at the limit were followed by only a single
worker being active.
Because this->thread is also read by threads that don't hold the
mutex the previous implementation was problematic (especially since
pthread_t is an opaque type of unknown length).
Fixes#654.
This won't hurt as long as sets and validators are of the same class.
But as soon as one of the object's class is changed this will cause
either a compile error (best option), or result (most likely) in a
crash.
Signed-off-by: Thomas Egerer <[email protected]>
Martin Willi