Tobias Brunner [Thu, 5 Jun 2014 17:06:34 +0000 (19:06 +0200)]
android: Show a confirmation dialog before importing certificates
Since the import activity can be triggered by any other app on the
system we shouldn't just import every certificate we get.
Also, in some situations (e.g. if no passphrase has been set yet for the
system-wide certificate store) we are the only application that can open
certificate files. So if a user clicked on a certificate file she would
just get a confirmation Toast about a successful import, with no indication
whatsoever where the certificate was actually imported. The new dialog
shows the app icon to indicate that strongSwan is involved.
Martin Willi [Thu, 17 Jul 2014 07:32:22 +0000 (09:32 +0200)]
receiver: Send a single INVALID_MAJOR_VERSION notify for IKE version > 2
We sent both a notify using IKEv1 and IKEv2. This is a little more aggressive
than required, RFC 5996 says we "SHOULD send an unauthenticated Notify
message of type INVALID_MAJOR_VERSION containing the highest (closest) version
number it supports".
Martin Willi [Mon, 7 Jul 2014 13:49:04 +0000 (15:49 +0200)]
settings: Be more strict in converting settings to specific data types
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.
Martin Willi [Mon, 7 Jul 2014 13:27:19 +0000 (15:27 +0200)]
enumerator: Enumerate glob(3) matches using gl_pathc
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.
Martin Willi [Fri, 4 Jul 2014 08:14:13 +0000 (10:14 +0200)]
kernel-netlink: Rename algorithm identifier from cast128 to cast5
Even if the XFRM identifier was named cast128 in the kernel before 2.6.31, it
actually never worked, because there is no such crypto algorithm.
The identifier has been changed to cast5 in
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=245acb87
to make it work, so we should use that.
Martin Willi [Tue, 1 Jul 2014 08:33:25 +0000 (10:33 +0200)]
gcrypt: Use predefined pthread locking functions instead of custom hooks
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.
Martin Willi [Wed, 25 Jun 2014 14:06:59 +0000 (16:06 +0200)]
windows: Include <sys/stat.h> explicitly before overloading memset()/memcpy()
fstat() in newer MinGWs is defined as non-static inline. With our new static
inline memset()/memcpy() overloads, this raises a warning. To avoid it,
explicitly include <sys/stat.h> once before defining these overloads.
Martin Willi [Tue, 24 Jun 2014 12:43:38 +0000 (14:43 +0200)]
charon: Set CLOEXEC flag on daemon PID file and /dev/(u)random source FDs
On Fedora, SELinux complains about these open file descriptors when the
updown script invokes iptables. While it seems difficult to set the flag
on all file descriptors, this at least fixes those covered by the SELinux
policy.
As these two cases are in code executed while the daemon is still single
threaded, we avoid the use of atomic but not fully portable fdopen("e") or
open(O_CLOEXEC) calls.
Tobias Brunner [Tue, 24 Jun 2014 12:52:42 +0000 (14:52 +0200)]
utils: Add wrappers for memcpy(3), memmove(3) and memset(3)
These wrappers guarantee that calls to these functions are noops if the
number of bytes is 0, as calling them with NULL pointers is undefined
according to the C standard, even if the number of bytes is 0 (most
implementations probably ignore the pointers anyway in this case, but
lets make sure).