g_rand_new() reads /dev/urandom and falls back to timestamp and pid.
At this point, we already unsuccessfully tried getrandom()/urandom,
so that doesn't seem promising to try.
Try harder to get good random seeds for our GRand instance.
Have one global instance, that gets seeded with various things that come
to mind. The random sequence of that instance is then used to initialize
the thread-local GRand instances.
Maybe this is all snake oil. If we fail to get good randomness by using
kernel API, what can we do? But really, callers also don't know how they
should handle a failure to get random data (short of abort() or
logging), so there is value in nm_utils_random_bytes() trying really
the best it can, and callers pretending that it doesn't fail.
This aims to improve the fallback case.
_nm_thread_local is very neat, but when we allocate resources
we need to make sure that they are destroyed when the thread
exits.
We can use pthread_setspecific() for that, but using it is cumbersome.
Add a helper function to make that simpler.
Also, the number of possible pthread_key_t keys is limited. With this
way, we only need one key in total.
We have two GKeyfile files (timestamps and seen-bssids).
When a profile was deleted while NetworkManager was running, then
entries were removed from these keyfiles. But if a profile disappeared
while NetworkManger was stopped, then those UUIDs piled up.
This also happens if you have temporary connections in /run and reboot.
We need a way to garbage collect entries that are no longer relevant.
As the keyfile databases only get loaded once from disk, we will prune
all UUIDs for which we have no more connection loaded, on the first time
we write out the files again.
Note what this means: if you "temporarily" remove a connection profile
(without NetworkManager noticing) and restore it later, then the additional
information might have been pruned. There is no way how NetworkManager
could know that this UUID is coming back. The alternative is what we did
before: pile them up indefinitely. That seems more problematic.
Previously, there was no limit how many seen-bssids are tracked.
That seems problematic, also because there is no API how to get
rid of an excessive list of entries.
We should limit the number of entries. Add an (arbitrary) limit
of 30.
But this means that we drop the surplus of entries, and for that it
seems important to keep the newest, most recently seen entries.
Previously, entries were merely sorted ASCIIbetically. Now, honor
their order (with most recently seen first).
Also, normalize the BSSIDs. From internal code, we should only get
normalize strings, but when we load them from disk, they might be bogus.
As we might cut of the list, we don't want that invalid entries
cut of valid ones. And of course, invalid entries make no sense at
all.
ifcfg-rh plugin never stored the seen bssid list to file, and
keyfile no longer does, and it's no longer parsed from GVariant.
So there is actually no way how anything could be set here.
The seen-bssids should only be populate from
"/var/lib/NetworkManager/seen-bssids". Nowhere else.
"wifi.seen-bssid" is an unusual property, therefore very ugly due to the
inconsistency.
It is not a regular user configuration that makes sense to store to
disk or modify by the user. It gets populated by the daemon, and
stored in "/var/lib/NetworkManager/seen-bssids" file.
As such, how to convert this to/from D-Bus needs special handling.
This means, that the to/from D-Bus functions will only serialize the
property when the seen-bssids are specified via
NMConnectionSerializationOptions, which is what the daemon does.
Also, the daemon ignores seen-bssids when parsing the variant.
This has the odd effect that when the client converts a setting to
GVariant, the seen-bssids gets lost. That means, a conversion to GVariant
and back looses information. I think that is OK in this case, because the
main point of to/from D-Bus is not to have a lossless GVariant representation
of a setting, but to transfer the setting via D-Bus between client and
daemon. And transferring seen-bssids via D-Bus makes only sense from the daemon
to the client.
"seen-bssids" primarily gets stored to "/var/lib/NetworkManager/seen-bssids",
it's not a regular property.
We want this property to be serialized/deserialized to/from GVariant,
because we expose these settings on the API like a property of the
profile. But it cannot be modified via nmcli, it cannot be stored
to ifcfg files, and it makes not sense to store it to keyfile either.
Stop doing that.
On RHEL-8.5, s390x with gcc-8.5.0-2.el8, we get a compiler warning:
$ CFLAGS='-O2 -Werror=maybe-uninitialized' meson build
...
cc -Isrc/libndhcp4-private.a.p -Isrc -I../src -Isubprojects/c-list/src -I../subprojects/c-list/src -Isubprojects/c-siphash/src -I../subprojects/c-siphash/src -Isubprojects/c-stdaux/src -I../subprojects/c-stdaux/src -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c11 -g -D_GNU_SOURCE -O2 -Werror=maybe-uninitialized -fPIC -fvisibility=hidden -fno-common -MD -MQ src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -MF src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o.d -o src/libndhcp4-private.a.p/n-dhcp4-c-connection.c.o -c ../src/n-dhcp4-c-connection.c
../src/n-dhcp4-c-connection.c: In function ‘n_dhcp4_c_connection_dispatch_io’:
../src/n-dhcp4-c-connection.c:1151:17: error: ‘type’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
uint8_t type;
^~~~
https://github.com/nettools/n-dhcp4/pull/24
nm-cloud-setup automatically detects routes, addresses and rules and configures them
on the device using the emphermal Reapply() API. That is, it does not modify the
existing profile (on disk), but changes the runtime configuration only.
As such, it used to wipe otherwise statically configured IP addresses, routes and
rules. That seems unnecessary. Let's keep the configuration from the (persistent)
configuration.
There is of course the problem that nm-cloud-setup doesn't really
understand the existing IP configuration, and it can only hope that
it can be meaningfully combined with what nm-cloud-setup wants to
configure. This should cover most simple cases, for more complex setups,
the user probably should disable nm-cloud-setup and configure the
network explicitly to their liking.
https://bugzilla.redhat.com/show_bug.cgi?id=1971527https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/893
This function is badly named, because it has no NMHostnameManager self
argument. It's just a simple function that entirely operates on a string
argument.
Move it away from "nm-hostname-manager.h" to "libnm-glib-aux/nm-shared-utils.h".
Hostname handling is complicated enough. Simple string validation
functions should not obscure the view on the complicated parts.
The numeric source IDs exist from a time before 2000, when there
was only one "GMainContext" singleton instance. Nowadays, the source
ID is only relative to one GMainContext, and you'd have to track
that association yourself. Als, g_source_remove() requires an additional
hash lookup, when you could simply track the GSource instance from the
start.
This API should not be used anymore. Operate on GSouce instances
direclty and use API like
nm_clear_g_source_inst()
nm_g_idle_add_source()
nm_g_idle_souce_new()
nm_g_source_attach()
g_source_attach
g_source_destroy
g_source_unref
etc.
Note that if you don't care about to ever remove a source again, like
scheduling an idle action that should not be cancelled, then
g_idle_add(callback, user_data);
is fine. It is only problematic to do something with those numeric IDs.
checkpatch.pl would also flag those uses, but these are just warnings
and in the few cases where such a warning is emitted wrongly, it's find
to ignore them.
Using the guint source ID always requires an additional hash lookup
during removal to find the real source instance. Use instead the
underlying GSource instance.
Searching over all sources in order to remove them is not what we want
to do. If you think you need these functions, instead keep track of the
GSource instances yourself.
I think this is non-obvious API, and should be pointed out. As we don't
really have a good place for this comment, the place is a bit unmotivated.
Still, add a comment.
