GitLab

Make the advanced section a separate dialog, as we do with the other
VPN plugins. Add also all the supported options that were still missing
from the GUI.

allow to properly manage also GtkCheckButton widgets and GtkComboBox
ones that allow three-valued logic values ("yes", "no" and an optional
third one value, dependent on the property).
This will allow a more convenient way to init new widgets (we are going
to leverage this in the next commit).

refactor the code a bit, should not change behavior

When passing the left/right identifier to libreswan, always
prepend the id the '@' char but when:
- the id is an IP address
- the id already starts with '@'
- the id starts with '%'

#4
!6

https://bugzilla.redhat.com/show_bug.cgi?id=1557035
!5

Not all the single options will be available (yet), just expose a simple
certificate-based IKEv2 template on the UI.

When writing Libreswan configuration, add the nm-configured paramter to
let Libreswan know that NetworkManager is taking care of the connection.

Till now the value "%defaultroute" was always enforced. Let it be the
default but allow also to specify a different one if needed.

Introduce support to the 'leftrsasigkey', 'rightrsasigkey' and
'leftcert' libreswan options.
The certificate or the RSA private key referenced in the options should
be already installed in the NSS database in order to allow the plugin to
connect successfully.

When the esp and ike options were not specified, we forced
ike=aes-sha1 and esp=aes-sha1;modp1024
These ciphers today are quite a low security standard. In particular the
DH group 2 (modp1024) has been downgraded to "SHOULD NOT" in RFC 8247 and
will be completely removed from libreswan 3.26.
So, we need to update the default crypto, also if it will affect existing
connections.

Let the default crypto be unspecified: this will allow libreswan to use
as default many sets of crypto proposals, to be negotiated with the remote
peer. Do this for IKEv2 and IKEv1 in main mode.
An exception should be made for IKEv1 connections in aggressive mode:
there the DH group in the crypto phase1 proposal must be just one; moreover
a total of 4 proposal only may be specified.
So, when IKEv1 aggressive mode is configured, use "ike=aes256-sha1;modp1536"
and "esp=aes256-sha1", that should be accepted by all obsolete VPN SW/HW
acting as a remote access VPN server and is supported in the forthcoming
version of libreswan.

The defaults we enforced for ikelifetime/salifetime when not specified
were taken to match default IKEv1 Cisco VPN client configurations (or so
I guess). Anyway, 24h is really a bad default from a security PoV. This
does not make any sense for newer IKEv2 configurations: better to let
Libreswan to pick its own defaults (currently 1h).

Add support to the 'rightid', 'narrowing', 'rekey', 'fragmentation' and
'mobike' Libreswan options

Add the brand new option 'ikev2', which maps the libreswan option of the
same name. When the option is found and is set with a value that enables
IKEv2, the option itself is passed as-is to libreswan while all the
XAUTH options are skipped (they are still added when the configuration is
IKEv1 based).
The configuration passed to libreswan will be of type IRAC (IPsec Remote
Access Client), enforcing CP mode. Anyway, no EAP method will be used as
it is not yet available in libreswan.

Group all the options related to XAUTH in the configuration passed to
libreswan. This shouldn't cause any change in behavior.
This change will allow to easily skip all XAUTH related configuration
when enabling the IKEv2 support.
IKEv2 support will be added in the following commit.

'esp' has been made obsolete 8 years ago: let's start to use the "new"
'phase2alg' option.

document the available options for vpn.data and vpn.secrets for the
NetworkManager-libreswan plugin.

"IPSec" was still present in very few places. Let us be coherent and
always use the preferred "IPsec" capitalization.

Quote from RFC 4301:
'The spelling "IPsec" is preferred and used throughout this and all
related IPsec standards.  All other capitalizations of IPsec (e.g.,
IPSEC, IPSec, ipsec) are deprecated.'

https://bugzilla.redhat.com/show_bug.cgi?id=1401860
!3

Change the order of the gtk objects specification in the xml file
to match the order in which they appear in the user interface:
basically order by top_attach/left_attach. No value is changed.

In the meanwhile, change label ids to something meaningful.

https://bugzilla.redhat.com/show_bug.cgi?id=1401860

!1

The pipeline begins with "build" stage doing a distcheck on Fedora 28
(which is still known to ship libnm-glib) and outputting a tarball
artifact.

The output is then used in the "test" stage.

In future, builds on some older platforms, CentOS and Ubuntu and clang
builds would be nice. Not implemented at this point, but it should be
straightforward enough.

Maybe a build with a Git snapshot of NetworkManager and/or
network-manager-applet would be useful at some point, but that's not
implemented either.

It's not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, libtool just
ends up not linking to some .la libraries.

Don't assume it's there.

It's a not necessarily present among the packages in a minimal
installation (such as Fedora's docker image). Worse even, configure just
ends up passing wrong linker flags on some architectures, without a word
of complain.

Don't assume it's there.