Bug 377473 - Plasma-nm doesn't store connection passwords encrypted anymore
Summary: Plasma-nm doesn't store connection passwords encrypted anymore
Status: RESOLVED DUPLICATE of bug 387502
Alias: None
Product: plasma-nm
Classification: Plasma
Component: editor (show other bugs)
Version: 5.8.5
Platform: Kubuntu Linux
: NOR major
Target Milestone: ---
Assignee: Jan Grulich
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2017-03-10 19:59 UTC by Theresa
Modified: 2018-09-30 00:31 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
plasma-network-manager debug (29.66 KB, text/plain)
2017-03-14 19:51 UTC, Theresa
Details
kded5 debug (14.62 KB, text/plain)
2017-04-14 18:39 UTC, Theresa
Details
KWalletManager5 (53.03 KB, image/png)
2017-04-19 19:15 UTC, Theresa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Theresa 2017-03-10 19:59:22 UTC
Hi,

I'm currently running kubuntu 16.04.2 with plasma-nm (4:5.8.5-0ubuntu1~ubuntu16.04~ppa1) and it seems I can no longer store passwords (WiFi and VPN) in my connect-manager

the only workaround that solves the problem is when I go into Wi-Fi security and select "Store password and make it available for all users (unencrypted)".
The same thing goes for credentials (password) for VPN connections.

If encrypted it says "Waiting for authorization" until it gives in and says "No secrets were provided". When I then go into the connection editor there are really no credentials/password stored. It's empty, although it was there before I tried to connect.

Syslog says:
Mar 10 20:56:49 herex NetworkManager[970]: <warn>  [1489175809.8764] device (wlp58s0): No agents were available for this request.
Mar 10 20:56:49 herex NetworkManager[970]: <info>  [1489175809.8764] device (wlp58s0): state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Mar 10 20:56:49 herex NetworkManager[970]: <warn>  [1489175809.8768] device (wlp58s0): Activation: failed for connection 'we_can_hear_you_FUCK'
Mar 10 20:56:49 herex NetworkManager[970]: <info>  [1489175809.8801] device (wlp58s0): state change: failed -> disconnected (reason 'none') [120 30 0]
Mar 10 20:56:49 herex kernel: [ 1492.145831] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready

Is there anything else I could check? Why it's no longer working in the encrypted mode? I feel rather uneasy now :(

cheers,
theresa
Comment 1 Jan Grulich 2017-03-13 07:02:43 UTC
See https://techbase.kde.org/Projects/Solid/Plasma-nm#Plasma-nm_doesn.27t_remember_my_password

It looks that our kded module is not running.
Comment 2 Theresa 2017-03-14 19:51:55 UTC
Created attachment 104568 [details]
plasma-network-manager debug
Comment 3 Theresa 2017-03-14 19:52:03 UTC
Hi Jan,

yes it definitely seems so:

systemctl status kded5
● kded5.service
   Loaded: not-found (Reason: No such file or directory)
   Active: inactive (dead)

should this be the service that you were talking about?

how would I start it? it doesn't seem to load through 
systemctl start kded5

please find attached other information that was requested from the link you've provided.

best,
theresa
Comment 4 Theresa 2017-03-17 17:59:00 UTC
Hi Jan,

any advice on how to fix this?

Best,
theresa
Comment 5 Jan Grulich 2017-03-21 12:01:48 UTC
Our kded module appears to be running. Problem could be in KWallet, can you check whether you have it enabled and whether plasma-nm is not accidentaly blocked? If I remember correctly before storing/loading passwords you should get a prompt whether plasma-nm can interact with KWallet and you might have accidentaly ignored it.
Comment 6 Theresa 2017-04-12 19:35:35 UTC
Hi Jan,

unfortunately this is not the case as Kwallet is running:

tm        1913     1  0 21:27 ?        00:00:00 /usr/bin/kwalletd5
tm        2253     1  0 21:27 ?        00:00:00 /usr/bin/kwalletd5 --pam-login 15 18
tm        2463  2355  0 21:27 ?        00:00:00 /usr/bin/kwalletmanager5 -session 10e0657265000148882876000000034130029_1492025218_888983

Also, I was asked by KWallet if I wanted to allow the access from NetworkManager

However, doing a tail on /var/log/syslog shows the following
Apr 12 21:29:44 herex NetworkManager[927]: <warn>  [1492025384.5414] device (wlp58s0): No agents were available for this request.
Apr 12 21:29:44 herex NetworkManager[927]: <info>  [1492025384.5415] device (wlp58s0): state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Apr 12 21:29:44 herex NetworkManager[927]: <warn>  [1492025384.5420] device (wlp58s0): Activation: failed for connection 'Wifi'
Apr 12 21:29:44 herex NetworkManager[927]: <info>  [1492025384.5426] device (wlp58s0): state change: failed -> disconnected (reason 'none') [120 30 0]
Apr 12 21:29:44 herex kernel: [  137.607891] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7890] device (wlp58s0): Activation: starting connection 'Wifi' (79a71c8c-a898-4012-b631-7f14d00bc068)
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7891] audit: op="connection-activate" uuid="79a71c8c-a898-4012-b631-7f14d00bc068" name="Wifi" pid=2410 uid=1001 result="success"
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7892] device (wlp58s0): state change: disconnected -> prepare (reason 'none') [30 40 0]
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7896] device (wlp58s0): state change: prepare -> config (reason 'none') [40 50 0]
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7898] device (wlp58s0): Activation: (wifi) access point 'Wifi' has security, but secrets are required.
Apr 12 21:29:55 herex NetworkManager[927]: <info>  [1492025395.7898] device (wlp58s0): state change: config -> need-auth (reason 'none') [50 60 0]
Apr 12 21:31:55 herex NetworkManager[927]: <warn>  [1492025515.8085] device (wlp58s0): No agents were available for this request.
Apr 12 21:31:55 herex NetworkManager[927]: <info>  [1492025515.8085] device (wlp58s0): state change: need-auth -> failed (reason 'no-secrets') [60 120 7]
Apr 12 21:31:55 herex NetworkManager[927]: <warn>  [1492025515.8089] device (wlp58s0): Activation: failed for connection 'Wifi'
Apr 12 21:31:55 herex kernel: [  268.880993] IPv6: ADDRCONF(NETDEV_UP): wlp58s0: link is not ready
Apr 12 21:31:55 herex NetworkManager[927]: <info>  [1492025515.8095] device (wlp58s0): state change: failed -> disconnected (reason 'none') [120 30 0]

plasma-nm keeps saying "Waiting for authorization".

Unencrypted passwords work....but what's the point, right?

Is there any other way how we could troubleshoot this?

cheers,
theresa
Comment 7 Jan Grulich 2017-04-13 07:41:28 UTC
This is weird, indeed. From the NM log it again appears that our module is not running. You didn't provide all the information I request, I still need you to enable the debug output and restart kded5 to see debug log from our module. Follow last part of https://techbase.kde.org/Projects/Solid/Plasma-nm#Plasma-nm_doesn.27t_remember_my_password.
Comment 8 Theresa 2017-04-14 18:39:29 UTC
Created attachment 105026 [details]
kded5 debug

Hi Jan,

please find attached the request debug.
The first output is from enabling the debugging and re-starting kded5 again.
It automatically restarted the network manager and tried to re-connect to the wifi, but failed. (hopefully you can see something).

The second output is from me killing all kded5 processes and re-starting kded5. Interestingly this time it asked me if I allowed KWallet-Manager to allow to save the passwords, and afterwards it asked for the Wi-Fi password. Exactly the way I wanted it to be, and then it worked, yay!!

However, I then rebooted my machine to see if it was boot-persistent and then it didn't work again anymore, until I killed all kded5 processes and restarted it. (It didn't ask for KWallet or Wifi password) but it still worked, I'm now connected to the wifi.

This is odd, seems like it wouldn't start properly after starting a Plasma session, right?
Hopefully, you can see something from the debug log...

Jan, thanks for all your help so far :)
Comment 9 Theresa 2017-04-14 18:40:50 UTC
Hi Jan,

please find attached the request debug.
The first output is from enabling the debugging and re-starting kded5 again.
It automatically restarted the network manager and tried to re-connect to the wifi, but failed. (hopefully you can see something).

The second output is from me killing all kded5 processes and re-starting kded5. Interestingly this time it asked me if I allowed KWallet-Manager to allow to save the passwords, and afterwards it asked for the Wi-Fi password. Exactly the way I wanted it to be, and then it worked, yay!!

However, I then rebooted my machine to see if it was boot-persistent and then it didn't work again anymore, until I killed all kded5 processes and restarted it. (It didn't ask for KWallet or Wifi password) but it still worked, I'm now connected to the wifi.

This is odd, seems like it wouldn't start properly after starting a Plasma session, right?
Hopefully, you can see something from the debug log...

Jan, thanks for all your help so far :)
Comment 10 Jan Grulich 2017-04-18 12:44:55 UTC
Hmm, still no idea what could be wrong.

Could you please open kwalletmanager5 and go to "Network Management" and search for your connection, it won't be displayed under its name, but you might recognize it by the password. I just want to check whether passwords are properly saved and problem is in getting them or they are not saved at all and problem is because it expects them to be saved but cannot find them.
Comment 11 Theresa 2017-04-19 19:15:44 UTC
Created attachment 105103 [details]
KWalletManager5
Comment 12 Theresa 2017-04-19 19:28:21 UTC
Hi Jan,

it seems KWalletManager5 is able to store the passwords, if I click on "Show values" the password is stored there. That's the way it should work, right?

If I click on the "Applications" tab in KWalletManager5 then it lists the following applications that are authorized to access the wallet:

*) Kwalletmanager5
*) ksshaskpass
*) Google Chrome
*) kded5

so it seems kded5 (plasma-nm) should be able to access the wallet.

The only workaround that works at the moment is "kill all kded5 processes" and then start kded5 by running /usr/bin/kded5

I've found this error in the debug mode:

plasma-nm: Unhandled active connection state change:  1
plasma-nm: virtual NMVariantMapMap SecretAgent::GetSecrets(const NMVariantMapMap&, const QDBusObjectPath&, const QString&, const QStringList&, uint)
plasma-nm: Path: "/org/freedesktop/NetworkManager/Settings/1"
plasma-nm: Setting name: "802-11-wireless-security"
plasma-nm: Hints: ()
plasma-nm: Flags: 1
Pass a valid window to KWallet::Wallet::openWallet().
plasma-nm: bool SecretAgent::processGetSecrets(SecretsRequest&) const Waiting for the wallet to open

Is this worrying?

cheers,
theresa
Comment 13 Jan Grulich 2017-04-20 07:07:16 UTC
Would you be able to compile plasma-nm if I send you a patch with some additional debug output? I think I won't be able to tell what could be wrong in your case without that.
Comment 14 user2304 2017-06-02 13:46:45 UTC
Hi,

although using kde-plasma 5.8.6 (Debian 9), this bug occured here within the last 2 weeks:

- All wifi-keys are stored in kwallet
- trying to connect won't bring up the kwallet password dialog
- there's a dialog to enter the wifi-key instead
- there's an error message of plasma-nm:

plasma-nm: bool SecretAgent::processGetSecrets(SecretsRequest&) const Waiting for the wallet to open

- creating a new connection, the password is not stored in kwallet and there's a similar message:

plasma-nm: bool SecretAgent::processGetSecrets(SecretsRequest&) const Waiting for the wallet to open

Filed a bug to the debian-bug-team too (863971).

user2304
Comment 15 user2304 2017-06-02 13:49:00 UTC
Little mistake, in case of trying to store a new connection, i get:

plasma-nm: virtual void SecretAgent::SaveSecrets(const NMVariantMapMap&, const QDBusObjectPath&)
Comment 16 user2304 2017-06-02 13:50:22 UTC
Sorry, the right message is:

plasma-nm: bool SecretAgent::processSaveSecrets(SecretsRequest&) const Waiting for the wallet to open
Comment 17 Anthony Youngman aka Wol 2017-08-06 20:51:56 UTC
This sounds related to my problem. I can't get the "workaround" of "Store password and make it available for all users (unencrypted)" to work. Running openSUSE 42.2 it seems it *INSISTS* on storing the password in kdewallet. So I have a nasty catch-22 ...

If my ~ is on the network (mine isn't - other users are) then I can't log in until the network is running, but the network won't start until I've logged in and enabled access to my kdewallet!
Comment 18 Jan Grulich 2017-09-11 11:41:33 UTC
*** Bug 381578 has been marked as a duplicate of this bug. ***
Comment 19 Jan Grulich 2017-10-03 08:10:07 UTC
*** Bug 371524 has been marked as a duplicate of this bug. ***
Comment 20 Jan Grulich 2017-10-23 10:06:29 UTC
*** Bug 385406 has been marked as a duplicate of this bug. ***
Comment 21 onitake 2017-10-23 18:10:54 UTC
I'm not sure if #385406 is the same issue as this one.

WLAN settings are stored just fine in my keychain. Loading or editing does not throw the "No secrets were provided" error.
There was a brief period a while ago when I had this issue with WLAN as well, but it seems it was fixed in the meantime.
The system is running Debian testing with plasma-nm 5.10.5.

I only hit this issue with WWAN (mobile broadband) connections. In this case, it's extra annoying, because I get popups for PIN code, superuser password and PPP password.

Can you send me your debugging output patch, Jan?
I'll give it a test and send you the output.
Comment 22 jeremy9856 2017-12-15 12:06:10 UTC
I was about to pass an exam, a powerpoint presentation, so the examiner spelled me the wifi password and after pressing ok an other windows ask for the wifi password! Quite embarrassing...
Comment 23 jeremy9856 2017-12-15 12:06:43 UTC
*** This bug has been confirmed by popular vote. ***
Comment 24 Nate Graham 2017-12-16 17:00:17 UTC
Jan, is there anything I can do to help you investigate this issue?
Comment 25 Jan Grulich 2018-01-02 09:43:29 UTC
I believe that this problem is in some wrong configuration, wrongly configured KWallet. I'm not able to reproduce this problem. For mobile broadband connections this issue is in NetworkManager and already reported upstream.
Comment 26 Frederick Zhang 2018-01-02 17:56:03 UTC
My issue (#381578) was marked as duplicated of this one, which mentioned the problem that passwords entered via the tray menu were not stored. And from a certain point of time, it just stopped prompting for passwords in the tray and a window always pops up instead for this purpose.

I deem the specific issue described in my ticket has been fixed somehow but the other issue that I'm experiencing is that Wi-Fi does not get connected automatically after login. The logs I got looked exactly like the ones from Theresa. I can wait until it fails or manually abort the attempt, then manually select a hotspot again from the tray menu and it would be all fine.
Comment 27 Frederick Zhang 2018-01-18 03:58:47 UTC
Well, surprisingly it actually behaves differently with different WiFi's.

When using with my company's WiFi, it still prompts me for the password in the tray, which does not work, and then pops up a window again to let me reenter it. But once the password is stored, there's no issue like being not able to connect to it after boot. I used "nmcli" to print out the info of both the WiFi's at my home and in my company but found no difference that could be related.

And when using with my uni's WiFi, which's adopted enterprise encryption, it's just completely flawless.

Maybe I'd better try clearing all the data of KWallet again. @Jan Could you please suggest the files that are needed to be removed to reset KWallet?
Comment 28 Jan Grulich 2018-01-30 15:14:14 UTC
*** Bug 389594 has been marked as a duplicate of this bug. ***
Comment 29 Jan Grulich 2018-02-07 08:08:58 UTC
*** Bug 389830 has been marked as a duplicate of this bug. ***
Comment 30 Jan Grulich 2018-02-23 10:39:25 UTC

*** This bug has been marked as a duplicate of bug 387502 ***
Comment 31 abugreporter 2018-09-30 00:31:01 UTC

*** This bug has been marked as a duplicate of bug 387502 ***