Move initialization of NMSettingBridge from NMPlatformLnkBridge to separate
function.
This is needed because this initialization will be used in more than one
function.
We store the timestamp when a profile activated the last time to
"/var/lib/NetworkManager/timestamps". There was also a timer which
would update the timestamp of activated connections every 300 seconds.
That seems unnecessary, drop it.
For one, waking up every 5 minutes and rewriting a file to disk seems
undesirable, for example if /var is a device where unnecessary writes
should be minimized.
Note that we already update the timestamp when a device goes down,
and of course when it comes up. Updating the timestamp in between seems
unnecessary.
This reverts commit 607350294d ('core: update timestamp in active
system connections every 5 mins (bgo #583756)').
An alternative would be to only update the timestamp in memory (so that
it would appear updated on D-Bus), but delay writing the file until
something important happens. `nm_key_file_db_*()` already tracks whether
there are changes ("dirty") and whether it's necessary to write the
file. It would be possible to track two dirty flags: one that requires
immediate update, and one that only ensures we will re-write dirty files
eventually.
See-also: https://bugzilla.gnome.org/show_bug.cgi?id=583756https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1171
Our convention is that a function that fails MUST set the GError output.
No need to check for that in nm_crypto_is_pkcs12_data(). Simplify the
error paths.
Also, in gnutls' _nm_crypto_verify_pkcs12(), don't call gnutls_pkcs12_deinit()
before gnutls_strerror(). It's unclear whether that couldn't set a
different error reason.
It has no actual dependency on the crypto library. All it does, is
to be careful about not leaking secrets in memory. We have code
for that in libnm-glib-aux already. Move.
The goal is to reduce the number of places where we use libnm-crypto,
because that has a large dependency. libnm-glib-aux is a very light
dependency instead.
libnm-core is also used by the daemon, thus currently dragging in
libnm-crypto there. But could we ever drop that dependency?
One use of the libnm-crypto is in functions like nm_utils_file_is_certificate()
in "nm-utils.h". These are part of the public API of libnm.
But this is not used by the daemon. Move it to "libnm-client-core"
to be closer to where it's actually used.
As we have unit tests in "libnm-core-impl/tests" that test this function,
those unit tests also would need to move to "libnm-client-impl".
Instead, add the actual implementation of these function to "libnm-crypto"
and test it there.
This patch moves forward declarations from public header "nm-utils.h" to
"nm-client.h". Arguably, "nm-client.h" is not a great name, but we don't
have a general purpose header in "libnm-client-public", so use this.
Note that libnm users can only include <NetworkManager.h> and including
individual files is not supported (and even prevented). Thus moving
the declarations won't break any users.
libnm-core currently has a dependency on crypto libraries (either
"gnutls", "nss" or "null"). We need this huge dependency for few cases.
Move the crypto code to a separate static library"src/libnm-crypto/libnm-crypto.la".
The reasoning is that it becomes clearer where we have this dependency,
to use it more consciously, and to be better see how it's used.
We clearly need the crypto functionality in libnm. But do we also need
it in the daemon? Could we ever link the daemon without crypto libraries?
The goal of splitting the crypto part out, to better understand the
crypto dependency.
"nm-error.h" is public API of libnm, and contains error numbers and
quarks. Clearly our "nm-crypto" implementation wants to use those
errors.
I want to move "nm-crypto" out of libnm, and as it's more basic, I think
it should not have a dependency on all of libnm-core. Also because
libnm-core currently uses nm-crypto, so there would be a circular
dependency. Which would be possible to do (libnm-core-aux-intern is
also used in such a way). But it's better avoided, to have clear
hierarchy of dependencies.
Add a version of the same error codes to libnm-base. libnm-base is a
very basic dependency (just one step above libnm-glib-aux).
nm_utils_bin2hexstr() is part of public libnm API.
That means, if we want to use this function, we need to link with
libnm-core-impl.
This is used by "nm-crypto.c". That file is currently part of
libnm-core, but that will change.
Move the implementation to libnm-glib-aux, so that we can use this code
from all our glib-based code (because all our glib-based code is allowed
to link with libnm-glib-aux).
When a static function only has one caller, it is often simpler to not
have the code in a separate function. Drop need_private_key_password()
and move it to need_secrets_tls().
g_warning() for unexpected scheme is not right. Either, this should be an
assertion (and never be hit), or the library should be silent about conditions
that can happen regularly.
I think code is easier to understand, if the difference (between phase1
and phase2) is pushed to the bottom. Having one large "if(phase2){}else{}"
at the top makes it harder to compare the two branches and see where
they differ.
When no radio hardware is present in the system, "nmcli radio"
currently displays:
WIFI-HW WIFI WWAN-HW WWAN
enabled enabled enabled enabled
which is misleading. Use the new RadioFlags property to display
"missing" in the *-HW columns when there is no hardware for the
given radio technology.
https://bugzilla.redhat.com/show_bug.cgi?id=1996918
Introduce a RadioFlags property on the manager object. For now it
contains two bits WLAN_AVAILABLE, WWAN_AVAILABLE to indicate whether
any radio interface is present in the system. The presence of a radio
is detected by looking at devices and rfkill switches.
In future, any radio-related read-only boolean flag can be exposed via
this property, including the already existing WirelessHardwareEnabled
and WwanHardwareEnabled properties.
Previously, only the daemon was writing keyfiles, and it ensures
that they are always valid.
As we now have this function as public API of libnm, we should drop this
restriction and write the profile the best we can. Granted, an invalid
profile may not be expressed in keyfile format, and the result is
undefined. But make the best of it.
This is severe. We cache the list of names, and we must invalidate the
cache when the names change. Otherwise, out-of-bound access and crash.
Fixes: d0192b698e ('libnm: add nm_setting_option_set(), nm_setting_option_get_boolean(), nm_setting_option_set_boolean()')
Fixes: 150af44e10 ('libnm: add nm_setting_option_get_uint32(), nm_setting_option_set_uint32()')
If __VA_ARGS__ contains odd arguments, it's not clear that N_ARG() gives
the same as the array initialization. Add a static assert that the
numbers agree to catch wrong usage of the macro.
For example:
nm_gobject_notify_together(setting, a, b, );
If we can't find a connection for any reason other than that it doesn't
exist, we should error out immediately and consistently, regardless of
whether we already encountered a non-existent connection.
This will allow migrating a connection. If specified, the connection will
be confined to a particular settings plugin when written back. If the
plugin differs from the existing one, it will be removed from the old one.
We expect to read NUL terminated strings. Upon NUL, we should do
something. Treat it as a line break.
Fixes: 8ae9cf4698 ('Revert "libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()"')
This partially reverts commit 4a9fcb0fc3, which replaced one-byte
reads with buffered ones in the VPN service plugin.
Unfortunately the buffering means that commands coming after the magic
"DONE" string were being pulled into the buffer. Secrets agents expect
a "QUIT" to come after the "DONE", and since with buffering "QUIT" was
in the buffer, this led to a twenty-second delay on every VPN
connection using a secrets manager.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1164
Fixes: 4a9fcb0fc3 ('libnm: buffer reads in nm_vpn_service_plugin_read_vpn_details()')
The GMainLoop instance (and the default GMainContext singleton) is not
required for trivial operations like --print-config, --version or
--help). If running as SysV daemon, the event file descriptor is
unnecessarily dup'ed from the parent to the child process.
Signed-off-by: Christian Eggers <ceggers@arri.de>
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1160
