No, sorry, but this is false.
It was true for opensuse 13.2, and it was true for Leap when released. It was already false for Tumbleweed when I tested this in January (see this blog post dated Jan 16). It is false for Leap after recent updates.
The current behavior for Leap and Tumbleweed, is that the network key for a system connection is in KDEwallet. When you first login to KDE, you are prompted for the root password (by polkit) for authorization to supply the network key for a shared connection, and you are prompted to open kwallet. I think the root request comes first, though that’s from memory. There is a central configuration file in “/etc/NetworkManager/system-connections”, but the network key is not being stored there when the shared connection is setup in KDE. The key is still stored centrally (as a line in that configuration file) if the connection is setup in Gnome, XFCE, etc.
If you had already setup the shared connection before the recent Leap updates, then the key is already stored centrally so you won’t run into this problem. If you now make a connection shared with Leap or with Tumbleweed, you will run into exactly this problem.
Or am I misunderstanding something here?
Yes. You are basing this on old knowledge. Your previous experience is no longer relevant.
Actually I’m on 5.5.5 now though (but when I tried this it was with earlier versions), which will be released as update for Leap as well soon.
I have not tried it with 5.5.5. I suppose I could install “krypton” or “argon” on an external drived connected to my laptop, and test this if you think it important. My suspicion is that it will be the same as I have been seeing in my tests with 5.5.4.
In any case, if the root password is requested for connecting, something is indeed going wrong. (changing the configuration does require the root password in openSUSE’s default polkit rules)
Yes, I agree. It seems to be using the wrong polkit rule. It is using the rule for changing a system connection. But supplying a network key does not change the system connection unless key is saved centrally (in the definition file for the connection). Since the key is only provided for the one-time connection, a different polkit rule should be used.
So, in my opinion, storing the key locally was a bad decision. But, given that decision, the polkit rule being used is wrong, and that is clearly a bug.
Doesn’t mean that there might not be a bug in plasma-nm5 though.
This changed recently on Leap. As far as I know, there hasn’t been a NetworkManager change, though there is an update waiting for me now. It looks to me as if “plasma-nm5” and “LibKF5NetworkManagerQt6” are the only things that have recently changed that might conceivably be involved.
I expect that the relevant change in “plasma-nm5” was to retain the key in kwallet, and not ask NetworkManager to store it centrally when making a system connection.
As a first step to investigate, it would be helpful to know what exact polkit rule forces the root password request. This can be seen in the “Details” in the password dialog.
I’m pretty sure that it is the rule to change a system connection. But that’s from memory. I never wrote that down. To me, the real problem is storing the network key by user (i.e. in kwallet) instead of storing it centrally.
If you want, I can delete all defined connections, set it up again, then check the “Details” (and write it down this time).