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 558331 - Save VPNC Group Password Only
Save VPNC Group Password Only
Status: RESOLVED DUPLICATE of bug 346547
Product: NetworkManager
Classification: Platform
Component: VPN: vpnc
git master
Other Linux
: Normal major
: ---
Assigned To: Dan Williams
Dan Williams
: 527576 558734 559794 (view as bug list)
Depends on:
Reported: 2008-10-29 02:36 UTC by Gilbert Mendoza
Modified: 2008-11-14 11:27 UTC
See Also:
GNOME target: ---
GNOME version: ---

Description Gilbert Mendoza 2008-10-29 02:36:32 UTC
Correct me if I'm wrong, but there appears to be a serious regression in functionality of NM's VPNC password management.  This was working fine with NM VPNC 0.6.X included with Ubuntu Hardy. 

In many configurations, including my own, a VPN client will be configured with a static group name and password for phase 1 authentication.  This password is saved in the keyring appropriately.

However, the user password should be allowed to be left blank so that it can be entered on each connection.  This is essential for use with One Time Passwords, such as RSA SecureID and other time/event based password systems where the user password is always changing.

In previous versions, the group passwords was able to be saved, and when you would connect, the group password would be filled in, but the user password would be left blank for someone to type in their new password.  With the current version you must enter both passwords and either save for the session or in the keyring.  Subsequent logins will fail unless you log out, or remove both passwords from the keyring to start everything all over again.

I tried to also work around the issue by deleting only the user password from the keyring, but I'm still prompted for the both the user and group password.  If I enter the user password and leave the group password blank hoping that it would use the one in the keyring, it's passed as blank.

1. Allow option to save "Group Password Only"
2. Allow option to "Always prompt for username and/or password"
Comment 1 Mathieu Trudel-Lapierre 2008-10-30 14:38:30 UTC
This was working because of a patch that was applied specifically to the Ubuntu package, not something that is in the 0.6.x or HEAD code.

There was a patch suggested in bug #363918 ( (roughly the same as was applied to the Ubuntu packages), but it is not applied to HEAD because there are inherent usability issues with it.

There is another possible patch ( but it needs review before anything can be done with it.
Comment 2 Dan Williams 2008-11-01 03:09:57 UTC
*** Bug 558734 has been marked as a duplicate of this bug. ***
Comment 3 Dan Williams 2008-11-01 04:06:52 UTC
Patch is still in my review queue, thanks for the work :)
Comment 4 Dan Williams 2008-11-03 19:09:50 UTC
I think that's gonna break the other VPN plugins unless we update them too; better to do a fully self-contained vpnc implementation with the GConf keys like I described in the mail to the list...
Comment 5 Mathieu Trudel-Lapierre 2008-11-03 20:31:03 UTC
Indeed, it likely would.

Fortunately, that's quite easy to change -- I can either remove the part were it's only prompting for the missing data, and the stuff would be there and showing properly. It also means that it would no longer affect the other plugins.

On the other hand, to keep that kind of functionality, I would just need to know how to get the GConf keys from within the auth-dialog helper. Would it be allowable to do that?

Also, I was wondering if anything else should be changed/cleaned up.
Comment 6 Dan Williams 2008-11-14 11:22:46 UTC
*** Bug 559794 has been marked as a duplicate of this bug. ***
Comment 7 Dan Williams 2008-11-14 11:24:19 UTC
*** Bug 527576 has been marked as a duplicate of this bug. ***
Comment 8 Dan Williams 2008-11-14 11:27:57 UTC
turns out this is actually the same as 346547

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