To embrace inclusive language, deprecate the NMSettingConnection
slave-type property and introduce port-type property.
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
The `ustar` format that is used to generate NM tarballs only supports
a 21-bit uid/gid causing the `make dist` command (or similar commands involving
tar archive creation) fails for users with high UIDs. This commit
changes the tar format from `ustar` to `pax` format which does not have such
limitation and is aligned with future plan to switch to meson
build system (which already uses the `pax` format).
When deleting a profile, the confirmation dialog shows "Cancel" and
"Delete" buttons. ESC key should do nothing, but in some distributions
like Debian and Ubuntu newt has a downstream patch that enables it (see
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584098).
In that case, when pressing ESC the return value of the dialog is not
"Cancel" (1) or "Delete" (2), but the "otherwise" value (0). Fix it by
not checking if "Cancel" is pressed. Instead, check if "Delete" was
pressed, and continue deleting only in that case.
Also, fix the doc comment that incorrectly says that the dialog returns
0/1 for the buttons, it is 1/2.
If a generated connection matches a connection that uses interface name
as controller, we need to drop the existing value from the settings to
avoid conflicts. Therefore, both of them need to be dropped; controller
and master.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1833
Fixes: 3e4a2ebb3c ('all: use the new NMSettingConnection Controller property')
Signed-off-by: Fernando Fernandez Mancera <ffmancera@riseup.net>
Previously, the tarball generated by `meson dist` did not contain the
autogenerated documentation due to the way meson works (packaging the
latest revision control commit). This introduces a dist script which
builds & copies the generated documentation into the distribution
tarball.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1811
Mark the methods/properties deprecated in the D-Bus API (via
org.freedesktop.DBus.Introspectable.Introspect(), [1]).
It affects those properties that are documented as deprecated in
introspection XML.
$ busctl -j call \
org.freedesktop.NetworkManager \
/org/freedesktop/NetworkManager \
org.freedesktop.DBus.Introspectable \
Introspect | \
jq '.data[0]' -r | \
grep -5 Deprecated
[1] https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-introspectable
Note that some of those sandboxing options may require relatively
recent systemd. In that case, to run against older systemd, you
will need to patch the service file. I don't think there is
a way around that, and limiting outselves to only the oldest supported
option is harmful for users who run recent systemd.
See-also: https://fedoraproject.org/wiki/Changes/SystemdSecurityHardening
A IPv4 conflict detected during the probe is a serious problem, as it
prevents the address from being configured. As such, is should be
displayed at warning level.
A conflict detected after the address is already configured
(addr_info->state == NM_L3_ACD_ADDR_STATE_CONFLICT) is less important
because NM will try to defend the address and will keep using it.
A duplicate address is a serious issue which leads to non-working
setups or problems hard to debug. Enable IPv4 duplicate address
detection (aka ACD, RFC 5227) by default to detect such problems.
While the RFC recommends a timeout of 9 seconds, a comment in n-acd
sources says:
A 9s timeout for successful link setups is not acceptable today.
Hence, we will just go forward and ignore the proposed values. On
both wired and wireless local links round-trip latencies of below
3ms are common. We require the caller to set a timeout multiplier,
where 1 corresponds to a total probe time between 0.5 ms and 1.0
ms. On modern networks a multiplier of about 100 should be a
reasonable default. To comply with the RFC select a multiplier of
9000.
Set a default timeout of 200ms, which is the double of the value
suggested in n-acd sources. 200ms sounds quick enough, and gives at
least ~100ms to other hosts to reply.
See also the Fedora change proposal:
https://fedoraproject.org/wiki/Changes/Enable_IPv4_Address_Conflict_Detection
"nm-property-compare.c" only contains nm_property_compare(), which is
broken.
It tries to compare string dictionaries as equal regardless of the
order of elements. It gets it wrong, for dictionaries with duplicate
keys. Which means, it can only be used with trusted variants that are
known to not contain duplicates. Which is quite a non-starter.
Also, the idea of a compare function for GVariant that ignores the order
of dictionary elements seems wrong. Even if for a certain application
the order does not matter, it still depends what the upper layer makes
of duplicate keys (will they bail out, or take the first/last occurrence
of a duplicate key?). nm_property_compare() doesn't have the knowledge
how upper layer handles it, and it's not obvious what's the right
choice. For example, if you use g_variant_lookup(), the first occurrence
is preferred. If you iterate over the children, possibly later
occurrences overwrite earlier ones.
It's ill defined, and maybe shouldn't be done. What should instead
happen, is that upper layers normalize (sort, uniquify) the keys, so
that we can do a full comparison. For that we have nm_g_variant_cmp().
Drop the now unused code. The core of the function still exists as
nm_g_variant_cmp().
There is g_variant_equal(), which can handle all variant types (however
that is not a compare function).
There is g_variant_compare(), which is a compare function but only works for
basic types.
Add nm_g_variant_cmp() which works with all variant types.
This is based on nm_property_compare(), with some differences:
- nm_property_compare() tries (wrongly) to accept string dictionaries in
any order. That functionality seems wrong, and nm_g_variant_cmp()
doesn't do that.
- nm_property_compare() does possibly not support all variant types.
This can be a problem, if we call the function on untrusted data
(and it can be hard to validate first, whether the function can
be called with a particular variant). Instead, nm_g_variant_cmp()
should work with all variants.
The unit tests are copied from "src/libnm-core-impl/tests/test-compare.c"
with some adjustments (because nm_property_compare() is not the same as
nm_g_variant_cmp()).
Note that the code is actually unused. It was written as replacement for
nm_property_compare(), but turns out not to be used there. For now,
leave it, because it might still be useful to have in the toolbox and it
exists (including tests).
nm_property_compare() makes a misguided attempt to compare dictionaries
regardless of their order.
However, if variants contain duplicate keys, then the implementation
is wrong and cannot handle it correctly.
Regardless of that. While in some sense the order of dictionary keys is
irrelevant, this is not the right place to perform such normalization.
If the order of things doesn't matter, then NMSetting must normalize the
property (e.g. by sorting the keys). At that point, the GVariant shall
be compared fully.
The supervision address is read-only. It is constructed by kernel and
only the last byte can be modified by setting the multicast-spec as
documented indeed.
As 1.46 was not released yet, we still can drop the whole API for this
setting property. We are keeping the NMDeviceHsr property as it is a
nice to have for reading it.
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1823
Fixes: 5426bdf4a1 ('HSR: add support to HSR/PRP interface')
Rename _nm_gobject_notify_together_impl##suffix() to
_nm_gobject_notify_together_full_v##suffix(). This name makes a bit more
sense. The "_v" suffix indicates that this takes an array of properties.
Also, commonly, when we have an array and a length parameter, the array comes
first. Reorder the arguments.
With `nmcli connection modify`, later options should overwrite earlier
ones. That did not work correctly with
nmcli --offline connection add type wifi \
wifi.ssid xxxx \
wifi.cloned-mac-address permanent \
wifi.mac-address-randomization 0
That's because "wifi.mac-address-randomization" is a mostly redundant
alias for certain "wifi.cloned-mac-address" options, and libnm does
various normalizations to make that somewhat seamless.
However, once "cloned-mac-address" property is set, setting any value of
"wifi.mac-address-randomization" has no effect, as it gets normalized
away by libnm. This is a sensible thing to do, in most cases to best
handle the deprecation/aliasing.
For nmcli, if the user sets "wifi.mac-address-randomization", it really
means to also reset the "cloned-mac-address". Thus nmcli needs to do
extra work to get this right.
The previous code is not entirely obvious, because as always,
verify() and normalize() must agree in what they are about to
do.
Make that clearer by adding _nm_setting_wireless_normalize_mac_address_randomization(),
which evaluates the desired settings. This is the used both by verify()
and normalize().
Some warnings in the generation of the translation files indicate real
errors, like strings that cannot be extracted for translations. Check
that no warnings are emitted.
Detected thanks to this message when generating the pot files:
id.po:14392: warning: internationalized messages should not contain
the '\v' escape sequence.
Due to the formatting of the string that contains it, it seems clear
that the \v character and the preceding work was put there by mistake.
Glib format specifiers are not gettext friendly. It even emits a
warning: src/core/main-utils.c:196: warning: Although being used in a
format string position, the msgid is not a valid C format string."
One possible solution is to use the equivalent format specifiers from
<inttypes.h> like PRId64, available since C99.
Even simpler is to cast the value to a type that is big enough to hold
it according to C specs (i.e. for int64: long long).
Fixes: 50f34217f9 ('main: use _nm_utils_ascii_str_to_int64 instead of strtol for reading pid')
