By passing as length of the MAC addresses -1 for both arguments, one
could get through to compare empty strings, NULL, and addresses longer
than the maximum. Such addresses are not valid, and they should never
compare equal (not even to themselves).
This is a change in behavior of public API, but it never made sense to
claim two addresses are equal, when they are not even valid addresses.
Also, avoid undefined behavior with "NULL, -1, NULL, -1" arguments,
where we would call memcmp() with zero length and NULL arguments.
UBSan flags that too.
When parsing user input if is often convenient to allow stripping whitespace.
Especially with escaped strings, the user could still escape the whitespace,
if the space should be taken literally.
Add support for that to nm_utils_buf_utf8safe_unescape().
Note that this is not the same as calling g_strstrip() before/after
unescape. That is, because nm_utils_buf_utf8safe_unescape() correctly
preserves escaped whitespace. If you call g_strstrip() before/after
the unescape, you don't know whether the whitespace is escaped.
Add a new "driver" match option to nm-settings. It allows to disable a
network connection configuration if a pattern is found or is not found
in the device driver name.
Add a new "kernel-command-line" match option to nm-settings. It allows
to disable a network connection configuration if a pattern is found or
is not found in /proc/cmdline.
With LTO, compiler warns:
libnm-core/nm-setting-bridge-port.c: In function nm_setting_bridge_port_remove_vlan_by_vid:
libnm-core/nm-setting-bridge-port.c:252:6: error: v_start may be used uninitialized in this function [-Werror=maybe-uninitialized]
252 | if (v_start == vid_start && v_end == vid_end) {
| ^
libnm-core/nm-setting-bridge-port.c:239:10: note: v_start was declared here
239 | guint16 v_start, v_end;
| ^
libnm-core/nm-setting-bridge-port.c:252:28: error: v_end may be used uninitialized in this function [-Werror=maybe-uninitialized]
252 | if (v_start == vid_start && v_end == vid_end) {
| ^
libnm-core/nm-setting-bridge-port.c:239:19: note: v_end was declared here
239 | guint16 v_start, v_end;
| ^
Avoid the (false positive) warning.
Conceptionally, the MUD URL really depends on the device, and not so
much the connection profile. That is, when you have a specific IoT
device, then this device probably should use the same MUD URL for all
profiles (at least by default).
We already have a mechanism for that: global connection defaults. Use
that. This allows a vendor drop pre-install a file
"/usr/lib/NetworkManager/conf.d/10-mud-url.conf" with
[connection-10-mud-url]
connection.mud-url=https://example.com
Note that we introduce the special "connection.mud-url" value "none", to
indicate not to use a MUD URL (but also not to consult the global connection
default).
