This is not ideal as the call to C_Finalize() should be the last one via
the PKCS#11 API. Since the order in which jobs are canceled is undefined
we can't be sure there is no other thread still using the library (it could
even be the canceled job that still handles a previous slot event).
According to PKCS#11 the behavior of C_Finalize() is undefined while other
threads still make calls over the API.
However, canceling the thread, as done previously, could also be problematic
as PKCS#11 libraries could hold locks while in the C_WaitForSlotEvent() call,
which might not get released properly when the thread is just canceled,
and which then might cause later calls to other API functions to block.
Fixes#2437.
This can happen if a stream is used blocking exclusively (the FD is
never registered with watcher, but is removed in the stream's destructor
just in case it ever was - doing this conditionally would require an
additional flag in streams). There may be no thread reading from
the read end of the notify pipe (e.g. in starter), causing the write
to the notify pipe to block after it's full. Anyway, doing a relatively
expensive FD update is unnecessary if there were no changes.
Fixes#1453.
This allows systemd socket activation by passing URIs such as systemd://foo
to plugins such as VICI.
For example setting charon.plugins.vici.socket = systemd://vici, a
systemd socket file descriptor with the name "vici" will be picked up.
So these would be the corresponding unit options:
[Socket]
FileDescriptorName=vici
Service=strongswan.service
ListenStream=/run/charon.vici
The implementation currently is very basic and right now only the first
file descriptor for a particular identifier is picked up if there are
multiple socket units with the same FileDescriptorName.
Signed-off-by: aszlig <[email protected]>
Closesstrongswan/strongswan#79.
The order of arguments in X509_CRL_get0_signature() is not the same as that
of X509_get0_signature().
Fixes: 989ba4b6cd ("openssl: Update CRL API to OpenSSL 1.1.0")
gperf is not actually a build dependency as the generated files are
shipped in the tarball. So the type depends on the gperf version on
the host that ran gperf and created the tarball, which might not be
the same as that on the actual build host, and gperf might not even
be installed there, leaving the type undetermined.
Fixes: e0e4322973 ("configure: Detect type of length parameter for gperf generated function")
Recent releases of glibc don't include the full stdint.h header in some
network headers included by utils.h. So uintptr_t might not be defined.
Since we use fixed width integers, including the latter, all over the place
we make sure the complete file is included.
Fixes#2425.
This fixes compilation with -Werror when using Clang 4.0 (but not 3.9)
and possibly prevents undefined behavior.
According to the C standard the following applies to the second
parameter of the va_start() macro (subclause 7.16.1.4, paragraph 4):
The parameter parmN is the identifier of the rightmost parameter
in the variable parameter list in the function definition (the
one just before the ...). If the parameter parmN is declared with
the register storage class, with a function or array type, or with
a type that is not compatible with the type that results after
application of the default argument promotions, the behavior is
undefined.
Because bool is usually just 1 byte and therefore smaller than int (i.e.
the result of default argument promotion) its use as last argument before
... might result in undefined behavior. This theoretically can also
apply to enums as a compiler may use a smaller base type than int.
Since Clang 3.9 (currently in use on Travis by default) a warning is
issued about this, however, that version did not yet compare the actual
size of the argument's type, causing warnings where they are not
warranted (basically for all cases where enum types are used for the
last argument). This was apparently fixed with Clang 4.0, which only
warns about this use of bool with va_start(), which makes sense.
They now match the dh_constructor_t signature. This is a follow up for
the changes merged with b668bf3f9e and should fix use of MODP_CUSTOM on
Apple's ARM64 platform.
The generic field of size 0 in the union that was used previously
triggered index-out-of-bounds errors with the UBSAN sanitizer that's
used on OSS-Fuzz. Since the two family specific union members don't
really provide any advantage, we can just use a single buffer for both
families to avoid the errors.
By definition, m must be <= n-1, we didn't enforce that and because
mpz_export() returns NULL if the passed value is zero a crash could have
been triggered with m == n.
Fixes CVE-2017-11185.
When requiring unique flags for CHILD_SAs, allow the configuration to
request different marks for each direction by using the %unique-dir keyword.
This is useful when different marks are desired for each direction but the
number of peers is not predefined.
An example use case is when implementing a site-to-site route-based VPN
without VTI devices.
A use of 0.0.0.0/0 - 0.0.0.0/0 traffic selectors with identical in/out marks
results in outbound traffic being wrongfully matched against the 'fwd'
policy - for which the underlay 'template' does not match - and dropped.
Using different marks for each direction avoids this issue as the 'fwd' policy
uses the 'in' mark will not match outbound traffic.
Closesstrongswan/strongswan#78.
Tobias Brunner