Hi,

I'd like to make a stable upload for network-manager.

Debian bullseye currently shis 1.30.0.
Upstream provides stable branches for 1.X, in this case 1.30.x, where
only bug fixes are backported. The current release from that branch [1]
is 1.30.6.

I've been shipping 1.30.6-1 in unstable for several without any reported
regressions and I'd like to ship that version for stable as well as a
simple rebuild.

The full debdiff is attached. If you prefer, I can provide a filtered
debdiff, where changes to build system and the generated .html files are
excluded.

Thanks for considering.

Regards,
Michael


[1] https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/tree/nm-1-30

Seeing that because of the attachment size, the debdiff didn't make it
to the list, I'm attaching a filtered diff without doc/autofoo generated
noise. (filterdiff -x "*/docs/*" -x "*/man/*" -x "*/configure")

 From the upstream NEWS file:


===============================================
NetworkManager-1.30.6
Overview of changes since NetworkManager-1.30.4
===============================================

* By default, don't touch existing traffic control (TC) configuration
   on devices.
* Send ARP announcements only when the interface gets carrier.
* Support the 'peer_notif_delay' bond option.
* Always start DHCPv6 on the default interface when an IPv6 prefix
   delegation is needed.
* Prefer the IPv4 address to determine the system hostname via address
   lookup.
* Support DHCP option 249 (Microsoft classless static route) with the
   internal nettools client.
* Force a restart of hostname resolution via DNS on signal SIGUSR1
   when resolv.conf is not managed by NetworkManager.
* Fix adding duplicate iptables rules for shared mode.
* Fix parsing of Wi-Fi Information Element (IE) for Microsoft Network
   Cost.
* Fix parsing of empty DHCP option 40 (NIS domain name) in the
   internal nettools client.
* Other various bugfixes.

===============================================
NetworkManager-1.30.4
Overview of changes since NetworkManager-1.30.2
===============================================

* Fix crash evaluating match setting properties (CVE-2021-20297).
* Fix leak of local route added by NetworkManager for configured
   addresses.
* Fix name of the device autoconnect D-Bus property.
* Multiple bugfixes in the initrd generator.
* Various minor bugfixes.

===============================================
NetworkManager-1.30.2
Overview of changes since NetworkManager-1.30.0
===============================================

* Increase the limit of open file descriptors in NetworkManager.service
* Fix hostname lookup via DNS when resolv.conf is managed by
   systemd-resolved
* Enable WPA3 for Wi-Fi connections with key_mgmt=WPA-PSK
* Fix crash with the IWD Wi-Fi backend
* Avoid logging warning when setting bond option
   "ad_actor_system=00:00:00:00:00:00"
* Update SpecificObject D-Bus property of ActiveConnection after WiFi
   roaming
* Multiple bugfixes in the initrd generator
* Various minor bugfixes




Am 18.09.21 um 20:41 schrieb Michael Biebl:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/tree/nm-1-30

Any news here? Anything I can do to help move this along?

Regards,
Michael

Am 03.11.21 um 15:33 schrieb Michael Biebl:

If there is no interest from the Debian side for such stable releases I
can pass that along to network-manager upstream to avoid them doing
unnecessary work.
This would be a shame though as they are very much interested in Debian
(stable).

Regards,
Michael

Hi Michael,

Sorry it took so long to get to this.  I've got a couple of questions
from the NEWS file; will keep looking at the actual diff though.

This sounds like it could cause unexpected changes.  Unsure about the
risk here.

Likewise.  What's the reasoning to do this in a stable update?

What's the regression risk here, of things working without WPA3 but not
with it enabled?

Cheers,
Julien

Nothing else jumps out at me from the diff, so while I'd welcome more
details on the risk analysis for the below, feel free to upload.

Cheers,
Julien

Hi Julien

Am 18.03.22 um 16:46 schrieb Julien Cristau:

The relevant bug report is
https://bugzilla.redhat.com/show_bug.cgi?id=1928078

 From the git commit
"
     core,libnm: don't touch device TC configuration by default

     NetworkManager supports a very limited set of qdiscs. If users want to
     configure a unsupported qdisc, they need to do it outside of
     NetworkManager using tc.

     The problem is that NM also removes all qdiscs and filters during
     activation if the connection doesn't contain a TC setting. Therefore,
     setting TC configuration outside of NM is hard because users need to
     do it *after* the connection is up (for example through a dispatcher
     script).

     Let NM consider the presence (or absence) of a TC setting in the
     connection to determine whether NM should configure (or not) qdiscs
     and filters on the interface. We already do something similar for
     SR-IOV configuration.

     Since new connections don't have the TC setting, the new behavior
     (ignore existing configuration) will be the default. The impact of
     this change in different scenarios is:

      - the user previously configured TC settings via NM. This continues
        to work as before;

      - the user didn't set any qdiscs or filters in the connection, and
        expected NM to clear them from the interface during activation.
        Here there is a change in behavior, but it seems unlikely that
        anybody relied on the old one;

      - the user didn't care about qdiscs and filters; NM removed all
        qdiscs upon activation, and so the default qdisc from kernel was
        used. After this change, NM will not touch qdiscs and the default
        qdisc will be used, as before;

      - the user set a different qdisc via tc and NM cleared it during
        activation. Now this will work as expected.

     So, the new default behavior seems better than the previous one.

"

I'd say the above reasoning makes sense to me.

 From the relevant git commit
"
     policy: prefer IPv4 to determine the hostname

     When determining the hostname, it is preferable to evaluate devices in
     a predictable order to avoid that the hostname changes between
     different boots.

     The current order is based first on hostname priority, then on the
     presence of a best default route, and then on activation order.

     The activation order is not a very strong condition, as it is
     basically useless for devices that are autoactivated at boot.

     As we already prefer IPv4 over IPv6 within the same connection, also
     prefer it when 2 connections have the same priority and the same
     default route status, to achieve better predictability.

https://bugzilla.redhat.com/show_bug.cgi?id=1970335

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/895
"

Makes sense to me as well.

That one I indeed missed. Thanks for spotting it. It has indeed the
potential to break existing setups (as evidenced by [1]), although I
think that would also need a newer wpasupplicant in stable.

The relevant upstream issue is
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638

I think reverting these commits for stable would make sense.

Julien, if I revert the three commits from this MR, would you be ok with
the upload?

Michael



[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003907
[2]
https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/638

Control: tag -1 confirmed
[...]
I wasn't arguing that any of these changes were bad, they do sound like
improvements, my question was around the potential for unexpected side
effects, which we try to avoid in stable, even when it means having to
live with known bugs.  I'm happy to trust your judgement there, just
wanted to raise this.

[...]
Yes.  Thanks for the due diligence.

Cheers,
Julien

Am 21.03.22 um 15:36 schrieb Julien Cristau:
Which version number should I pick?

a/ 1.30.6-1~deb11u1
b/ 1.30.6-1+deb11u1
c/ 1.30.6-2


I think, now that I have made changes (with the revert of the WPA3 bits)
compared to 1.30.6-1, b/ is the most suitable one. But I wanted to
double check before I upload.

Regards,
Michael

b/ sounds good :)

Thanks,
Julien

Am 21.03.22 um 15:56 schrieb Julien Cristau:

Uploaded.
Thanks a lot for your review, Julien.

Michael

package release.debian.org
tags 994622 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==============

Package: network-manager
Version: 1.30.6-1+deb11u1

Explanation: new upstream stable release

package release.debian.org
tags 994622 = bullseye pending
thanks

Hi,

The upload referenced by this bug report has been flagged for acceptance into the proposed-updates queue for Debian bullseye.

Thanks for your contribution!

Upload details
==============

Package: network-manager
Version: 1.30.6-1+deb11u1

Explanation: new upstream stable release

Hi,

Each of the requests discussed in these bugs was included in today's
bullseye point release.

Regards,

Adam