GNOME Bugzilla – Bug 638861
The networkmanager openconnect dialog doesn't store passwords in the GNOME keyring (or anywhere else)
Last modified: 2012-06-18 14:24:42 UTC
For my wireless connections, etc. NetworkManager will keep my password in my keyring so I don't need to retype it when I connect; however the networkmanager openconnect dialog doesn't do this and I need to retype it every time.
Patches welcome; this should be a lot easier now that the auth-dialog is present in the network-manager-openconnect repository in GNOME git. It would need to give us the *option* of storing passwords, rather than doing so unconditionally.
I second this. I heavily rely on most of those networkmanager vpn plugins and only this one seems to miss an option to store the password.
So, I tried implementing this, but I hit a road block: Other plugins, such as network-manager-vpnc seem to have ditched direct gnome-keyring access in favor of letting NM store the passwords in the configuration dialog. However, in the case of openconnect, there is not a single password. Instead, you are presented with a form, which can contain any amount of fields. What should we do about that? Do you have any pointers? For now, I tried storing all form values (not only the text/selection fields) and that works — but the password ends up in /etc/NetworkManager/system-connections/my-vpn-name. I guess this is not a secure location, right?
(In reply to comment #3) > So, I tried implementing this, but I hit a road block: > … There was no reply for over a month. Anyone? :-)
Sorry, I was travelling when you posted that and either didn't see it, or promptly forgot. Dan may have a stronger opinion but I suspect you're right, I don't think we want to be storing these passwords in NetworkManager's storage — we want to be using gnome-keyring for them. As you've seen, for the non-password form values we created a 'key' for each, based on the auth_id of the form and the name of the individual entry box. I would suggest that you make the key in the same way, but just store it using gnome_keyring_store_password_sync()¹ instead of handing it back to NetworkManager as a secret. Ideally I suppose you want to use the asynchronous gnome_keyring_find_password() rather than the _sync version, when you're actually interacting with the user. Unless you do it in advance from the libopenconnect thread, perhaps, but it would be nicer to do it in the main UI thread and fill in the textbox contents as and when the replies come back from gkr. ¹ http://developer.gnome.org/gnome-keyring/stable/gnome-keyring-Simple-Password-Storage.html#gnome-keyring-store-password-sync
Now fixed in git HEAD. Thanks for the patches.
Note that there are still potential improvements that could be made: - Currently the user still has to hit 'submit' manually even though the dialog has all the answers prepopulated. We could do that automatically.. as long as we notice a failure and don't keep doing it repeatedly if the password has changed. Since each form has an auth_id perhaps it would suffice just to ensure that you auto-submit only once for each auth_id. If you ever get the same form back again, you wait for the user to hit 'submit'. - We should store the *cookie* that results from successful authentication, perhaps in nm-openconnect-service itself, and use that for subsequent connections instead of re-authentication (which gives us a new IP address etc.)