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 363918 - Only save group password in keyring
Only save group password in keyring
Product: NetworkManager
Classification: Platform
Component: VPN: vpnc
Other Linux
: Normal normal
: ---
Assigned To: Dan Williams
Dan Williams
Depends on:
Reported: 2006-10-21 13:18 UTC by Denis Leroy
Modified: 2009-06-02 21:20 UTC
See Also:
GNOME target: ---
GNOME version: ---

Add option to save group password only (13.17 KB, patch)
2006-10-21 13:19 UTC, Denis Leroy
none Details | Review
Add "save group password" option (12.40 KB, patch)
2007-11-17 06:49 UTC, Denis Leroy
none Details | Review
save group password (9.36 KB, patch)
2008-10-08 03:41 UTC, Mathieu Trudel-Lapierre
none Details | Review

Description Denis Leroy 2006-10-21 13:18:49 UTC
We had a request for this feature, and I like the idea since in my vpn setup at work the main password is a use-once password from a keycard (so doesn't make sense to save it) while the group password is a low-security constant password.

I wrote a patch to add the option to nm-vpnc-auth-dialog. The patch is bigger than I had hoped as the code internally moves the keyring data as an unnamed link list, which is not convenient in the case where only 1 out of 2 passwords is present...
Comment 1 Denis Leroy 2006-10-21 13:19:46 UTC
Created attachment 75128 [details] [review]
Add option to save group password only
Comment 2 Dan Williams 2007-04-02 04:43:06 UTC
Any chance you could store the value of "Save group password in keyring" in GConf and check the checkbox appropriately?  The problem I've got is that I _don't_ use OTP and therefore I have to check the box again every time.
Comment 3 Denis Leroy 2007-04-04 09:17:01 UTC
Hmm, could you elaborate ? I'm not sure i understand.

Rignt now, the box is checked only if it obtained the actual group password from the keyring. Are you saying you're not using the keyring at all, and would like the group password saved unencrypted in GConf ? If that's the case, the group password probably belongs in the configuration dialog rather than in the authorization dialog...
Comment 4 Dan Williams 2007-04-04 14:33:39 UTC
No; what happens is this.  If the connection fails, the next time I try to connect the password dialog is brought up again.  That's correct.  It pre-fills both passwords from the keyring correctly.  What it _doesn't_ do is automatically check the "Save Group Password in Keyring" checkbox in the dialog, which I always want checked.  It always brings up the dialog with that box unchecked by default.  It does not save the value of the checkbox across failed connection attempts.

What it should do is save the state of that checkbox in GConf so that it is the same every time the dialog comes up.  I'd hazard a guess that you don't see this issue because you always want the dialog box unchecked because you don't want the group password saved.
Comment 5 Denis Leroy 2007-11-17 06:49:52 UTC
Created attachment 99246 [details] [review]
Add "save group password" option

Dan, I was revisiting this problem while porting the patch to F-8. Do you have any preferences on how to do this right ?

The problem is nm-vpnc-auth-dialog doesn't know its correct GConf path (i.e. the NMConnection number under /system/networking/connections/?).

Should nm-vpnc-auth-dialog 

1) store the "save password" preferences into its own directory, or

2) should it scan /system/networking/connections/ to figure out which subdirectory is "his" ?

3) should that preferences be stored by the calling layer ? (hmm, how?)

(updated patch attached)
Comment 6 Mathieu Trudel-Lapierre 2007-12-06 01:41:51 UTC
Has there been any development on this issue? I had included the initial patch posted by Denis that I had found on a Fedora CVS tree in a packaging for Ubuntu... I'll update with this new one, and watch for changes on this bug.
Comment 7 Mathieu Trudel-Lapierre 2008-10-08 03:41:35 UTC
Created attachment 120177 [details] [review]
save group password

Following the inclusion of the svn20080928t225540 snapshot in Ubuntu, I looked again into this issue and decided to attempt at adapting Denis Leroy's patch to what I guess is not too far from SVN HEAD (I hope).

I've attached my patch, hopefully it is in the right format and sane. Key changes are providing get functions for the specific secrets (user and group passwords) alongside the keyring_helpers_lookup_secrets, and allowing for the group password to be saved independently in the keyring -- the user password could also be made to support that with little changes.
Comment 8 2008-10-09 05:08:21 UTC
This is bug on LP.
Comment 9 Steve Brown 2009-01-02 06:46:06 UTC
Is it possible to further simplify the UI in both the config properties and auth dialog?  Instead of a combo box next to the password fields, how about just a simple checkbox?  This is more intuitive than a pop-up menu.  I think the callbacks should infer as much as possible for the sake of a clean UI.  Something like this:

                  .------------------------.  .---.
   User Password: | i4mvrl1337&^%          |  | X |
                  `------------------------'  `---'
                  .------------------------.  .---.
  Group Password: | my-GrOuP-PassWORD      |  | X |
                  `------------------------'  `---'

In [1], Dan gives three types of passwords: static, one-time-password, and blank.  A checkbox still satisfies these use-cases:

1) Static: user enters the password, checks the save box.  Keyring saves the password.  Gconf instructs vpnc to look in the keyring.  Future dialogs do not prompt for this password.
2) Blank: user leaves the field blank, checks the save box.  Keyring saves nothing (or maybe a special field-is-blank value.)  Gconf notes the field is intentionally blank.  Future dialogs do not prompt for this password.
3) OTP: user enters today's password.  Future auth dialogs prompt for this password.

In case of a mistake, or a new static password, the user could reset/reactivate the prompts by going to the config properties and unchecking the corresponding "save" checkbox.

I think a checkbox is cleaner and far more intuitive than a combo box.  Thoughts?

Comment 10 Mathieu Trudel-Lapierre 2009-05-29 17:59:40 UTC
Is it me or has this already been resolved in SVN? Is there a need to further discuss the UI?
Comment 11 Dan Williams 2009-06-02 21:20:34 UTC
Nah, should have been long resolved by the combo box next to password items that allows the user to specify [Saved, Always Ask, Not Required].