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 <thomas.egerer@secunet.com>
To avoid any race conditions when multiple threads call and initialize
diffie_hellman_get_params(), explicitly examine the optimum DH exponent size
during library initialization.
Fixes#655.
As the behavior was inconsistent for empty strings or strings with characters
appended to a number, testing the code failed on some platforms. The new rules
are more strict, returning the default if additional characters or an empty
string was found for a setting.
While glob should return a NULL terminated gl_pathv when having no matches,
at least on OS X this is not true when using GLOB_DOOFFS. Rely on the
number of matches returned in gl_pathc, which seems to be more reliable in
error cases.
Starting with libgcrypt 1.6, it seems that custom locking functions are not
supported anymore. Instead, the user has to select from one of the pre-defined
set of locking functions.
Given that we have a proper threading abstraction API with optional profiling
on all platforms, this is somewhat annoying. However, there does not seem to be
a way to use custom functions, and we have no other choice than using the
provided macro magic to support all libgcrypt versions.
Fixes#630.