GitLab

The new NMSettingMacsec contains information necessary to establish a
MACsec connection. At the moment we support two different MACsec
modes, both using wpa_supplicant: PSK and EAP.

PSK mode is based on a static CAK key for the MACsec key agreement
protocol, while EAP mode derives keys from a 802.1x authentication and
thus requires the presence of a NMSetting8021x in the connection.

https://bugzilla.gnome.org/show_bug.cgi?id=775181

The dns directory does not only contain the manager
instance, but various files related to DNS.

Rename.

The dhcp directory does not only contain the manager
instance, but various files related to DHCP.

Rename.

https://bugzilla.gnome.org/show_bug.cgi?id=774461

Fixes: 44b2044f

Remove Proxies from the list once proxy patches are successfully merged.

Fixes: 146e0d23

https://bugzilla.gnome.org/show_bug.cgi?id=771732

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

https://bugzilla.gnome.org/show_bug.cgi?id=770447

https://bugzilla.gnome.org/show_bug.cgi?id=769463
(cherry picked from commit 5e41e163)

https://bugzilla.gnome.org/show_bug.cgi?id=769463

https://bugzilla.gnome.org/show_bug.cgi?id=769463

https://bugzilla.gnome.org/show_bug.cgi?id=766927

This file is only used by plugins and copied between them.

It's purpose is to contain general utility functions that are
only relevant for implementing NetworkManager's VPN plugins.

In principle the utility functions could be part of libnm, however,
there are a few problems with that:
  - if they are part of libnm, adding and using a new utility function
    requires the plugin to bump the required libnm version. Since you
    usally can work around/reimplement utility functions, this results
    in not using the API from libnm, not adding the API to libnm,
    and reimplementing it over and over in the plugin.
  - plugins compile both against libnm and libnm-glib. Thus, either
    the utility function would also be needed in libnm-glib, or again,
    it is not usable by the plugin.

We must avoid that the utility functions diverge and no local
modifications to these files should be made in the plugin.
Instead, one special location of the utility functions shall be
extended and re-imported (copied) to the plugin as needed.

Add the files to NetworkManager's repository. Although they are not
needed for NetworkManager itself, they are a different API provided
by NetworkManager. An API that is reused and shared by copying the files
around.

The "shared" directory contains files that are possibly used by all components
of NetworkManager repository.

Some of these files are even copied as-is to other projects (VPN plugins, nm-applet)
and used there without modification. Move those files to a separate directory.
By moving them to a common directory, it is clearer that they belong
together. Also, you can easier compare the copied versions to their
original via

  $ diff -r ./shared/nm-utils/ /path/to/nm-vpn-plugin/shared/nm-utils/

Let VPN plugins return a virtual function table to extend
the API while bypassing libnm. This allows to add and use
new functionality to VPN plugins without updating libnm.

The actual definitions are in a header-only file
"nm-vpn-editor-plugin-call.h", which can be copied to the
caller/plugin.

Add new Reload D-Bus command to reload NetworkManager configuration.

For now, this is like sending SIGHUP to the process. There are several
advantages here:

  - it is guarded via PolicyKit authentication while signals
    can only be sent by root.

  - the user can wait for the reload to be complete instead of sending
    an asynchronous signal. For now, we operation completes after
    nm_config_reload() returns, but later we could delay the response
    further until specific parts are fully reloaded.

  - SIGHUP reloads everything including re-reading configuration from
    disk while SIGUSR1 reloads just certain parts such as writing out DNS
    configuration anew.
    Now, the Reload command has a flags argument which is more granular
    in selecting parts which are to be reloaded. For example, via
    signals the user can:

      1) send SIGUSR1: this writes out the DNS configuration to
         resolv.conf and possibly reloads other parts without
         re-reading configuration and without restarting the DNS plugin.
      2) send SIGHUP: this reloads configuration from disk,
         writes out resolv.conf and restarts the DNS plugin.

    There is no way, to only restart the DNS plugin without also reloading
    everything else.

https://bugzilla.gnome.org/show_bug.cgi?id=765787

https://bugzilla.gnome.org/show_bug.cgi?id=765974

https://bugzilla.gnome.org/show_bug.cgi?id=765985

Fixes: 753f727a

When performing NM package upgrade the new version of nmcli will be immediately
available while NM daemon will not, as it would not restart in order to avoid
to disrupt connectivity. This could create issues with tools leveraging
on nmcli output (till reboot). As apart from this case it is very unlikely
that a user can have this nmcli / NM daemon version mismatch situation,
the check could cause more harm than benefit in real user case
scenarios.

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

https://bugzilla.gnome.org/show_bug.cgi?id=764750

https://bugzilla.gnome.org/show_bug.cgi?id=764955

https://bugzilla.gnome.org/show_bug.cgi?id=764690

Seems like Zanata makes it easy to make this mistake if it's just a
warning.

Turn the string back to fuzzy if unsure.