This build option allowed non-admin users to create system-wide
connections. Generally, this is not a good idea as system-wide changes
should be done by administrators.
However, the main reason for the change is that this can be used to
bypass filesystem permissions, among possibly other attacks. As the
daemon runs as root, a user can create a system-wide connection that
uses a certificate from a different user to authenticate in a WiFi
network protected with 802.1X or a VPN, because as root user the daemon
can access to the file.
This patch does not completely fix the issue, as users can still create
private connections specifying a path to another user's connection. This
will be addressed in other patch. However, this patch is needed too,
because in system-wide connections we don't store which user created the
connection, so there woudn't be any way to check his/her permissions.
This is part of the fix for CVE-2025-9615
See: https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1809
Since both `NetworkManager.service` and `NetworkManager-initrd.service` are
allocated for the same bus name (`org.freedesktop.NetworkManager`) and this is
not allowed, the best option is to use a systemd generator to install them only
in the initrd, instead of setting fixed Install sections.
Fixes#1814
The URL to the tarball needs the git tag, that might be 1.54-rc1 instead
of 1.53.90. Allow to define it as a separate variable in the spec file.
It can be set as `git_tag_version %{real_version}` when they are
identical.
It is not really needed here in the upstream spec file, as the "Source"
line is commented out, but add it as a reference for donwstream spec
files.
They cannot be used yet as Dracut need changes. They are not really
tested, neither, so better not to install them as they might cause
confusion about their purpose.
Decouple from a specific initrd generator (dracut) the systemd services that
provide networking in the initrd using NM, thus allowing other systemd-based
initrd generators to take advantage of it.
These new services are:
- `NetworkManager-config-initrd.service`: it starts very early at boot, parses
the kernel command line using `nm-initrd-generator` and sets the
`/run/NetworkManager/initrd/neednet` flag to activate the other initrd services,
and also sets the hostname if needed.
- `NetworkManager-initrd.service`: it basically does the same job as the
`NetworkManager.service`, but in the initrd.
- `NetworkManager-wait-online-initrd.service`: ordered before
`network-online.target`, it will allow other services that require networking to
delay their start until NM has finished.
NetworkManager relies on the ping command provided by `/usr/bin/ping`
from the iputils package to proceed the gateway or ip addresses
connectivity check. This change ensures that iputils is recommended as a
dependency, making the ping command available for use during runtime but
not enforcing its installation as mandatory since NM can still proceed
to activate the connection even if the ping operation failed.
We are planning on completely dropping Autotools in the future.
This breaks the build process with an argument to ignore the deprecation,
so that anyone building NM is warned of this change.
Install a configuration snippet on Fedora 40+, that sets the default for
"wifi.cloned-mac-address" to "stable-ssid" (otherwise, the built-in default
is "preserve").
This will mean, that on Wi-Fi profiles that don't explicitly override
the property "wifi.cloned-mac-address", a stable address is generated.
The benefit is, that Fedora will randomize the MAC address by default.
Note that this also affects all pre-existing Wi-Fi profiles, that don't
explicitly configure the property in the profile. Depending on how you
see it, this is desirable. Randomization should be done, unless the user
opts-out (not the other way around).
Note that setting "wifi.cloned-mac-address=stable-ssid" is similar to
setting a stable ID "${NETWORK_SSID}" and "wifi.cloned-mac-address=stable".
The difference is that the latter also affects other properties, like
- "ipv6.addr-gen-mode=stable-privacy"
- "{ethernet,wifi}.cloned-mac-address=stable"
- "ipv4.dhcp-client-id=stable"
- "ipv6.dhcp-duid=stable-{llt,ll,uuid}"
- "{ipv4,ipv6}.iaid=stable"
Especially with "ipv6.addr-gen-mode=stable", changing the stable ID
would mean that also all IPv6 addresses change. We want to avoid that by
only changing the cloned-mac-address to "stable-ssid".
This means, after upgrade to F40, different MAC addresses will be used
on most users' Wi-Fi. This means, DHCP might hand out different IP
addresses, sessions might expire, and configuration that depended on the
previous MAC address will be affected.
https://pagure.io/fedora-workstation/issue/350
Now that we no longer test on CentOS7, we also have no more tests that
build using Python2.
Note that build with Python2 is currently broken already (which would be
fixable).
Drop Python2 too.
Existing Python scripts still use a common subset of Python2 and
Python3. They can be improved to use Python3 features in the future.
The license identifier was updated for the main package, but not for
libnm which overrides it to LGPL 2.1 or later. Update it too.
Fixes: 8c5aec7a1b ('contrib/rpm: migrate to SPDX license')
network-online.target should not be reached before nm-cloud-setup
completes configuring the network, which may make user service get
started before the network is fully configured.
Setting nm-cloud-setup.service as "Before=network-online.target" would
maybe have already achieved that. However, also use a pre-up dispatcher
script, so that the device activation in NetworkManager is also waiting
for nm-cloud-setup to complete.
https://bugzilla.redhat.com/show_bug.cgi?id=2151040https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1653
