| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Enable missing https:// support in the curl plugin by initializing libcurl
appropriately.
To initialize the SSL backend properly as required, we rely on our specific
crypto backends (openssl, gcrypt) that already provide this functionality.
Fixes #692.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
On Ubuntu 12.04, there seems to be a resource leak related to pthread keys
when initializing glib or related libraries more than once. With our repeated
initialization for libstrongswan tests, we hit the following error:
Lib (gthread-posix.c): Unexpected error from C library during
'pthread_key_create': Resource temporarily unavailable.
The problem is not reproducible on a newer Gnome stack, hence we disable the
glib based soup plugin until we have a more recent Ubuntu on Travis.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some fetcher plugins (such as curl) might build upon OpenSSL to implement
HTTPS fetching. As we set (and can't unset) threading callbacks in our
openssl plugin, we must ensure that OpenSSL functions don't get called after
openssl plugin unloading.
We achieve that by loading curl and all other fetcher plugins after the base
crypto plugins, including openssl.
|
| | |
|
| |
| |
| |
| |
| | |
This function is called by libcurl initialization with SSL, and uses
a static allocation of compression algorithms not freed.
|
|/
|
|
| |
If initialization fails, we fall back to the old behavior.
|
| |
|
|\
| |
| |
| |
| | |
In preparation for larger parallelization changes in kernel-netlink, this
merge does some general code cleanup in that plugin.
|
| |
| |
| |
| |
| | |
This allows a user to check if the watcher is actually running, and potentially
perform read operations directly instead of relying on watcher.
|
| | |
|
| |
| |
| |
| |
| | |
This avoid the hard dependency on enum names, and makes kernel_netlink_shared
independent of kernel_netlink_ipsec.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
As we are not interested in the returned address, there is really no need
in passing that argument.
|
| |
| |
| |
| | |
There is really no need for doing so, and it makes the code just unreadable.
|
|/
|
|
|
| |
This allows us to streamline the netlink buffers, and avoid extensive
casting.
|
|\
| |
| |
| |
| |
| | |
Introduces a systemd specific charon-systemd IKE daemon based on libcharon.
Uses systemd APIs for startup control and journal logging and a new systemd
service unit using swanctl as configuration backend.
|
| |
| |
| |
| |
| | |
Travis still uses Ubuntu 12.04, where no systemd libraries are available. Skip
systemd support on Travis until we have a more recent Ubuntu distribution.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This allows to (relatively) quickly (re-)build and install the current
or an arbitrary strongSwan source tree within the root image.
bindfs is used to bind mount the source directory using the regular user
and group (only works if sudo is used to run the script) so that newly
created files are not owned by root.
As with building the root image in general the guests must not be
running while executing this script. The guest images are automatically
rebuilt after the root image has been updated so configuration files and
other modifications in guests will be lost.
|
| |
|
| |
|
| |
|
|
|
|
| |
References #705.
|
|
|
|
| |
Fixes #705.
|
|
|
|
|
| |
The MOBIKE task is active during the initial exchanges but we don't want
to treat them as actual MOBIKE exchanges (i.e. there is no path probing).
|
|
|
|
|
|
|
|
|
| |
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange. By storing the last message block as IV
we can't decrypt the first block of such a response.
Fixes #661.
|
| |
|
|
|
|
| |
Fixes #661.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes #661.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
These changes improve the handling of MOBIKE tasks, for instance, when
retransmitting and no path is available.
Fixes #632.
|