The comment makes it sounds as if we could do without CAP_DAC_OVERRIDE
if we don't use OpenVSwitch, which is not true. At the very least it's
needed by the VPN plugins we spawn to access cert/key material from
users' homes.
For [connection*] and [device*] sections, any suffix is allowed in
the group.
However (at least for configuration snippets we ship upstream), we
want to give a suffix that matches the name of the configuration
snippet.
It seems more common to use [connection-*] instead of [connection.].
See also "examples/nm-conf.d/*.conf" and "15-carrier-timeout.conf" file
which contains a [device-15-carrier-timeout] section.
Note that this file (in Fedora) is not configuration (installed in
/usr/lib). It is thus not problematic to modify.
Fixes: ea8dbd7a6d ('contrib/rpm: add "22-wifi-mac-addr.conf" to F40+')
The group interface is only used during activation; there is no need
to add a pending action for it, because when the device is in
activating state it already delays "startup-complete" via other
pending actions.
The daemon is now capable of understanding and removing these prefix
tags by itself. It is better than this is not a responsibility of the
secret agent because it requires changes in all secret agents to work
properly (see https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536).
If the secret agent knows what these prefix tags are, it can remove them
only in the text that is displayed in the UI, but maintaining the
original string as the secret name that is returned to the daemon.
Secret agents that doesn't know what these prefix tags are won't do
anything with them, and they will also return the same string as secret
name, as expected. The only drawback is that they might display the full
string to the user, which is not a nice UX but it will at least work.
Also, allow to translate the secret name for the UI in libnmc.
Commit 345bd1b187 ('libnmc: fix secrets request on 2nd stage of 2FA
authentication') and commit 27c701ebfb ('libnmc: allow user input in
ECHO mode for 2FA challenges') introduced 2 new tags that hints for the
secret agents can have as prefix.
These tags were processed (and removed) in the secret agents, not in the
daemon. This is wrong because a system with an updated VPN plugin but a
not yet updated secret agent (like nm-plasma) will fail: it won't remove
the prefix and the daemon will save the secret with the prefix, i.e.
"x-dynamic-challenge:challenge-response" instead of just
"challenge-response". Then, VPN plugins doesn't recognize it, failing the
profile's activation. This is, in fact, an API break.
Also, if the VPN connection already existed before updating NM and the
VPN plugin, the secret flags are not added to the profile (they are only
added when the profile is created or modified). This causes the user's
first time response is saved to the profile, so the activation fails the
second and next times.
See:
- https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/1536
- https://gitlab.gnome.org/GNOME/NetworkManager-openvpn/-/issues/142
Anyway, in a good design the daemon should contain almost all the logic
and the clients should keep as simple as possible. Fix above's problems
by letting the daemon to receive the secret names with the prefix
already included. The daemon will strip it and will know what it means.
Note that this is done only in the functions that saves the secrets from
the data received via D-Bus. For example, nm_setting_vpn_add_secret
doesn't need to do it because this value shouldn't come from VPN
plugin's hints.
Add explanation of how to indicate the new issues workflow to
MAINTAINERS.md: triage -> investigation -> devel. The different
stages are indicated using Gitlab's scoped labels (mutually exclusive).
These stages try to hightlight that the issue cannot be fixed and it's
not moving forward because more info is needed, already. Also, add a
section to CONTRIBUTING.md highlighting the importance of helping in
the triage and investigation stages: developers often cannot fix bugs
because lack of time to investigate, but even users that doesn't know
how to fix it due to lack of knowledge of the code base can help thanks
to their knowledge on networking.
Finally, make the 'triage:issues' CI job to work again, adding some
new policies with new automations. The automation will add or remove the
labels: stale, help-needed::{triage, investigation, devel} and
unassigned.
The labels help-needed::* and unassigned will be automatically added to
all issues without an assignee. This reflects better the reality of not
having enough time to work on most of the issues unless there is some
external help.
With the deprecation of autotools, use meson by default. For the moment,
it's still possible to build with autotools passing -a/--autotools.
Additionally, as we allow to specify different build directories other
than './build', let's not asume that the user wants to overwrite it
by default. Instead, the script will asume ./build if the user doesn't
specify the build directory, but only if it doesn't exist. If it does,
the user will have to force overwritting it with `--meson ./build`.
Instead of forcing to use ./build directory, let's make the the user
specify what directory he wants to use. This will allow to have multiple
build directories with different configurations as meson is designed to
allow, without having to overwrite the existing build one.
As Fedora 41 (currently Rawhide) is migrating to DNF5 [1], the
debuginfo-install command is not available anymore according to the
documentation. Instead, the user need to add the package suffix
"-debuginfo" when using the install command.
The implementation of the debuginfo-install plugin is under development
and tracked upstream. [2]
[1] https://fedoraproject.org/wiki/Changes/SwitchToDnf5
[2] https://github.com/rpm-software-management/dnf5/issues/389
Note: here I refer to the numbers in a version as MAJOR.MINOR.MICRO.
Having stable and development releases do make sense for the MINOR
version, because we maintain separate branches for them and they
evolve separately. We have 1.47.z where we put all the changes so
anyone can pick the latest development release and test it. At the
same time, we have 1.46.z with the latest stable released version.
However, it does not make sense to have 1.46.2 and 1.46.3-dev because
the latter is not a development version. It is identical to 1.46.2,
only the version number has been bumped, there are no changes to test.
When we add commits, we will be actually testing 1.46.3-dev + some
commits, which is exactly the same as testing 1.46.2 + some commits.
So, basically, someone can use the releases of a development BRANCH,
like 1.47.4, to test the development version of NM. But using a
development MICRO version is exactly the same as using a
non-development one.
From now on, we will just increment the MICRO version each time we do a
release on a stable branch and won't create the '-dev' tag. Update
release.sh to do it this way.
Although VPN plugins are developed separately, better to document here
how to do the release of those that we maintain to avoid having to do
the changes on every repository each time.
Usually, when the method is "auto" we want to avoid configuring routes
until the automatic method completes. To achieve that, we clear the
"allow_routes_without_address" flag of l3cds when the method is "auto".
For VPNs, IP configurations with only routes are perfectly valid,
therefore set the flag.
The name "dhcp_enabled" is misleading because the flag is set for
method=auto, which doesn't necessarily imply DHCP. Also, it doesn't
convey what the flag is used for. Rename it to
"allow_routes_without_address".
An IPv4-over-IPv6 (or vice-versa) IPsec VPN can return IP
configurations with routes and without addresses. For example, in this
scenario:
+---------------+ +---------------+
| fd01::10/64 <-- VPN --> fd02::20/64 |
| host1 | | host2 |
+-------^-------+ +-------^-------+
| |
+-------v-------+ +-------v-------+
| subnet1 | | subnet2 |
| 172.16.1.0/24 | | 172.16.2.0/24 |
+---------------+ +---------------+
host1 and host2 establish a IPv6 tunnel which encapsulates packets
between the two IPv4 subnets. Therefore, in routed mode, host1 will
need to configure a route like "172.16.2.0/24 via ipsec1" even if the
host doesn't have any IPv4 address on the VPN interface.
Accept IP configurations without address from the VPN; only check that
the address and prefix are sane if they are provided.
Translatable strings were added to nm-setting-generic.c. Add this file to
POTFILES.in.
Fixes: 9322c3e9db ('libnm: add generic.device-handler property')
