Re: [PATCH] Saving only the group password in keyring



I wasn't aware of the confusing factor of having that specific
checkbox on the auth dialog, although I have to admit the difference
between the "session" keyring and the "permanent" one of the two
checboxes that are already there did throw me off a bit.

I'll see if I can put something together to implement your solution.
It does sound like a pretty good idea to me, especially since that
could also have the potential of requesting only the OTP passwords
where necessary.

/ Matt

On Thu, Oct 9, 2008 at 12:05 PM, Dan Williams <dcbw redhat com> wrote:
> On Thu, 2008-10-09 at 09:15 -0400, Mathieu Trudel-Lapierre wrote:
>> Hi,
>>
>> First, my apologies for pushing for this, since I believe the
>> interested parties are probably already notified through bugzilla on
>> this...
>
> So the reason this didn't get merged in the first place is that when
> this is used, the auth dialog looks like ass.  Having _3_ buttons there
> has confused every user I've ever seen, and makes me read things a few
> times whenever I get the dialog.  It's just bad UI.  Plus, it's not
> something you can change in the connection editor out-of-band from
> authentication.  That's not to say it doesn't fill a need and fix the
> bug, but the solution is not one I'd like to have upstream.
>
> Instead, we need a better solution.  We have two passwords, the user
> password and the group password.  Each password has 3 different types:
>
>                  u s e r
>         |  static  |  unused  | OTP
>   ------|----------|----------|------
> g  static|     Y    |    Y     |  Y
> r  ------|----------|----------|------
> o  unused|     Y    |    X     |  ?
> u  ------|----------|----------|------
> p  OTP   |     Y    |    Y     |  ?
>   ------|----------|----------|------
>
>    Legend:
>      Y = I've heard of it being used
>      X = Pointless
>      ? = I don't know if this is used by anyone
>
> The cases where you don't want to save passwords in the keyring are the
> OTP/RSA and the "unused" cases.
>
> Here's my solution: for each of the group and user password entries,
> have a small popup menu behind each on in the main config dialog like
> so:
>
>                  .------------------------.  .------------.
>   User Password: | i4mvrl1337&^%          |  | Default  |V|
>                  `------------------------'  `------------'
>                  .------------------------.  .------------.
>  Group Password: | my-GrOuP-PassWORD      |  | Default  |V|
>                  `------------------------'  `------------'
>
> Where the combo box has the following items:
>
>   Default     (ie, static password that rarely changes)
>   Interactive (ie, RSA dongles)
>   Unused      (ie, no password required and nothing saved to keyring)
>
> It always defaults to "Default" (ie, static) so most peoples configs
> will work, but you have to option to change it for your config.
>
> Note that Interactive authentication can't be used yet anyway because we
> don't support challenge-based authentication that it requires, which
> will come after 0.7 when I can rework the VPN cleanup patch I've talked
> about before, and will require
>
> If somebody came up with the UI patch to do this, that would be awesome
> and I'd commit it.  It would additionally mean adding two keys to the
> vpnc plugin's GConf data (user-password-type and group-password-type)
> which would then have to be added to the nm-vpnc-service's validation
> code and used internally if required, but that's pretty easy.  These
> keys would store the password type (as a string) so that the auth dialog
> would know when to save which passwords and which password entry widgets
> to disable/desensitize when the user had selected "unused".
>
> Thoughts?
>
> Next, we get to add authentication types to the client to support Hybrid
> Auth mode.  Not sure if you can use all the normal Xauth stuff (like
> interactive) with the hybrid auth mode as well, but I have to assume you
> can.
>
> Dan
>


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]