After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 728681 - [review] dcbw/auth-refactor: Can't connect to VPN: GLib.KeyFileError
[review] dcbw/auth-refactor: Can't connect to VPN: GLib.KeyFileError
Status: RESOLVED FIXED
Product: NetworkManager
Classification: Platform
Component: VPN: vpnc
unspecified
Other Linux
: Normal normal
: ---
Assigned To: NetworkManager maintainer(s)
NetworkManager maintainer(s)
: 728564 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-04-21 20:43 UTC by h.vorwerk
Modified: 2014-05-01 13:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
networkAgent: Handle empty vpn 'keyfiles' (1.81 KB, patch)
2014-04-23 06:55 UTC, drago01
none Details | Review
networkAgent: Handle empty vpn 'keyfiles' (1.81 KB, patch)
2014-04-23 06:57 UTC, drago01
committed Details | Review

Description h.vorwerk 2014-04-21 20:43:07 UTC
After updating to Gnome 3.12 (on arch), I can not connect to VPN anymore. I assume this is a Gnome-Shell bug and not networkmanager, because it appeared directly after update 3.10->3.12.

When I try to connect, it will silently fail. Log says: "JS ERROR: error while reading VPN plugin output keyfile: GLib.KeyFileError: Key file does not have group 'VPN Plugin UI'"

# journalctl -r

Apr 21 22:29:36 packardbell NetworkManager[301]: <error> [1398112176.912508] [nm-vpn-connection.c:1374] get_secrets_cb(): Failed to request VPN secrets #2: (6) No agents were available for this request.
Apr 21 22:29:36 packardbell gnome-session[680]: VPNRequestHandler<._readStdoutNewStyle/<@resource:///org/gnome/shell/ui/components/networkAgent.js:499
Apr 21 22:29:36 packardbell gnome-session[680]: wrapper@resource:///org/gnome/gjs/modules/lang.js:169
Apr 21 22:29:36 packardbell gnome-session[680]: VPNRequestHandler<._showNewStyleDialog@resource:///org/gnome/shell/ui/components/networkAgent.js:520
Apr 21 22:29:36 packardbell gnome-session[680]: (gnome-shell:775): Gjs-WARNING **: JS ERROR: error while reading VPN plugin output keyfile: GLib.KeyFileError: Key file does not have group 'VPN Plugin UI'
Apr 21 22:29:36 packardbell NetworkManager[301]: <info> VPN service 'vpnc' appeared; activating connections
Apr 21 22:29:36 packardbell NetworkManager[301]: <info> VPN service 'vpnc' started (org.freedesktop.NetworkManager.vpnc), PID 1700
Apr 21 22:29:36 packardbell NetworkManager[301]: <info> Starting VPN service 'vpnc'...

Deleting the connection in networkmanager and creating a new one does not solve the problem. Tell me if you need any further details.
Comment 1 Emmanuele Bassi (:ebassi) 2014-04-22 19:21:27 UTC
can confirm that it happens since my upgrade to GNOME 3.12 in Fedora using the COPR repository.
Comment 2 Dan Williams 2014-04-22 19:22:40 UTC
Which vpnc passwords are marked "Saved" in the configuration for the VPN connection?  Are any marked "always ask" or "not required"?
Comment 3 drago01 2014-04-22 20:19:22 UTC
When setting the password to "always ask" it works here with "saved" I see the same bug.
Comment 4 h.vorwerk 2014-04-22 21:16:34 UTC
can confirm that when any of the passwords is set to "always ask", it works. 
If both are to "saved", it doesn't. 

I didn't test the "not required" case because my VPN requires both passwords ;)
Comment 5 Dan Williams 2014-04-22 22:02:02 UTC
The cause looks like a combination of two things:

1) new GNOME Shell doesn't correctly handle the VPN plugin passing back nothing, which can happen if both passwords are saved, and is valid in some cases if both passwords are saved in the system

2) NetworkManager-vpnc *should* always pass back something to GNOME Shell, even if both passwords are saved.  It was not handling this case correctly, which is a bug that appears to have existed since the original external-ui-mode patches in 2011.

------

I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this issue.  Any testing would be appreciated.  I don't believe that GNOME Shell needs any changes at this time.

https://git.gnome.org/browse/network-manager-vpnc/log/?h=dcbw/auth-refactor

For Fedora users (either rawhide or F20) you can use the following scratch build of this upstream branch:

http://koji.fedoraproject.org/koji/taskinfo?taskID=6767238
Comment 6 drago01 2014-04-23 06:45:08 UTC
(In reply to comment #5)
> The cause looks like a combination of two things:
> 
> 1) new GNOME Shell doesn't correctly handle the VPN plugin passing back
> nothing, which can happen if both passwords are saved, and is valid in some
> cases if both passwords are saved in the system
> 
> 2) NetworkManager-vpnc *should* always pass back something to GNOME Shell, even
> if both passwords are saved.  It was not handling this case correctly, which is
> a bug that appears to have existed since the original external-ui-mode patches
> in 2011.
> 
> ------
> 
> I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this
> issue.  Any testing would be appreciated.  I don't believe that GNOME Shell
> needs any changes at this time.
> 
> https://git.gnome.org/browse/network-manager-vpnc/log/?h=dcbw/auth-refactor
> 
> For Fedora users (either rawhide or F20) you can use the following scratch
> build of this upstream branch:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=6767238

Yes I can confirm that this build fixes it for me.
Comment 7 drago01 2014-04-23 06:55:40 UTC
Created attachment 274929 [details] [review]
networkAgent: Handle empty vpn 'keyfiles'

Passing back no data is valid in case both secrets (group and user passwords)
are stored.

Just confirm the request in that case.

---

This should handle case 1)
(didn't test it though because I do not have build env set up on my rawhide box)
Comment 8 drago01 2014-04-23 06:57:38 UTC
Created attachment 274930 [details] [review]
networkAgent: Handle empty vpn 'keyfiles'

Passing back no data is valid in case both secrets (group and user passwords)
are stored.

Just confirm the request in that case.
Comment 9 Emmanuele Bassi (:ebassi) 2014-04-23 08:13:23 UTC
can confirm that the build on koji fixes the issue for me as well.
Comment 10 Emmanuele Bassi (:ebassi) 2014-04-23 08:15:08 UTC
Review of attachment 274930 [details] [review]:

looks good to me as an interim fix.
Comment 11 drago01 2014-04-23 11:10:10 UTC
Attachment 274930 [details] pushed as bccbcd8 - networkAgent: Handle empty vpn 'keyfiles'


Pushed a tested version with a small change.
Comment 12 drago01 2014-04-23 11:12:29 UTC
Cherrypicked the change into 3.12 as well ... now moving to NetworkManager to get Dan's fixes upstream and then we can closed it.
Comment 13 Dan Winship 2014-04-23 17:24:46 UTC
(In reply to comment #5)
> I've pushed the dcbw/auth-refactor branch of network-manager-vpnc to fix this
> issue.

>+eui_finish (const char *vpn_name,

>+	/* Only show an entry for a password if (a) we don't have it, and it's
>+	 * required, or (b) we're retrying authentication.  Obviously don't show
>+	 * anything if interaction is not allowed.
>+	 */

that needs some rewriting to make sense in the external-ui case

>+std_ask_user (const char *vpn_name,

This seems like it would be simpler if you made use of nma_vpn_password_dialog_set_show_password() to hide the user password slot when it wasn't needed, rather than moving the group password into the user password slot in that case.

>+get_passwords_required (GHashTable *data,

>+	if (hints && g_strv_length (hints)) {
>+		for (iter = hints; iter && *iter; iter++) {

"iter && *iter" can be just "*iter" since you already know hints != NULL.
Comment 14 Dan Williams 2014-04-28 16:11:28 UTC
Fixed up and repushed.
Comment 15 Dan Winship 2014-04-28 20:59:40 UTC
looks good
Comment 16 Dan Williams 2014-04-28 22:37:33 UTC
merged to git master
Comment 17 Dan Winship 2014-05-01 13:00:26 UTC
*** Bug 728564 has been marked as a duplicate of this bug. ***