Bug 478728

Created attachment 328156 [details]
A slightly cleaner patch (passing keyring items using available mechanism)

Also briefly tested. Appears to work.

Created attachment 328161 [details]
Avoid a segfault

That goto store may cause deallocation of items that have not been allocated. Fixed here.

Created attachment 328935 [details]
Patch against 0.8 source

Comment on attachment 328935 [details]
Patch against 0.8 source

This patch has been compiled and linked, but not tested.

I've been running the patch against 0.7 on my F-10 systems for many days now without any problems.

Created attachment 328942 [details]
Corrected patch against 0.8 source

This patch has been tested against 0.8 on F-10.

Created attachment 328951 [details]
Patch against 0.8 source with better memory management

Tested on F-10.

Created attachment 328956 [details]
Better patch against 0.8: attempt gnome keyring authentication once

Tested on F-10.

Instead of telling the user that the credentials have expired using the tray, we can try with gnome keyring stored password, which is also non-interactive. If that doesn't work (bad or no password in gnome keyring), just display they icon on the tray and wait for user to click it in order to provide password.

Created attachment 329153 [details]
Patch against 0.8 source: split keyring functionality into separate files

Tested on F-10.

Created attachment 329154 [details]
Patch against 0.8 source: split keyring functionality into separate files

OOPS! Git is different to svn. Take that into account when creating the patch.

I am afraid, that this is whole bug is pretty bad idea -- the point of Kerberos is that it should be ultra-secure -- circumvention of the Kerberos process by using passwords which cannot be controlled by administrators (and thus are presumably weaker) seems to me like totally bad idea.

I would vote for WONTFIX.

Well, that's already been circumvented if you're using Evolution and Exchange. Essentially, your Kerberos (AD) password will be stored in the keyring by Evolution.

What's the point of having a keyring if it cannot be trusted and you cannot store passwords in it?

One more observation here: AFAIK, if network authentication is used, default keyring (which is used for this) will have network password.

Had a look through gnome-keyring source and there is already a calculation of password strength there. Maybe the real solution is to use that calculation to enable system admins to enforce password strength on keyrings?

I think I should be able to whip up a patch along those lines...

Created attachment 329298 [details]
Enforce keyring password strength in gnome-keyring

Something like this. I didn't even compile this, let alone test it. But, you get the idea.

Created attachment 329408 [details]
Patch against 0.8 source: make keyring use optional

Given the objection that some system admins may not like this behaviour, here is a patch that makes the whole thing optional.

Created attachment 329409 [details]
Patch against 0.8 source: make keyring use optional

For real this time.

OK, I think I addressed the circumvention concern with two different improvements:

- enforcement of strong keyring passwords (for admins that choose to use keyring)
- keyring off by default (this can be enforced by mandatory profiles)

Matej,

Could you please comment on the above and if it passes the sanity test. If it doesn't, I'll close as WONTFIX.

Created attachment 329417 [details]
Patch against 0.8 source: make keyring use optional

Stay away from deleting passwords if keyring items were not allocated.

Would it be possible to add to this program something like applet functionality. I would love to have a green light in my taskbar turning red when ticket expires (is to expire?), and clicking on this equivalent of kinit would run. What do you think?

Except when there is no UI to enable the keyring use nobody will really use this feature.

I'm not really working on this anymore -- Colin, you've been somewhat active here, can you have a look, please?

Regarding comment #21 - that's how 0.8 and above works already. There is an applet and the icon changes and you get notified that your ticket expired. When you click the icon, you get your credentials renewed. You can turn this on or off using gconf.

With the use of keyring, your credentials get refreshed automatically and you get notified that it happened. If the password in the keyring is bad and the authentication fails (after being tried only once), it is removed from the keyring and you get the "ticket expired" icon again. You then need to click the icon to get the dialog again and this then stores the good password into the keyring.

Of course, use of keyring is optional and can be prohibited by admins by using mandatory profiles.

Created attachment 329924 [details]
Patch against 0.8 source: delete passwords if krb5_get_init_creds_opt_set_pkinit returns error

It seems to me that we should do this as well, so that we don't keep stale passwords in the keyring, which can cause authentication attempts with incorrect passwords. I have no way to test this - my system doesn't have krb5_get_init_creds_opt_set_pkinit() function.

Created attachment 329925 [details]
Patch against 0.8 source: never use keyring when pkinit is used

This is probably the safest bet, so that we don't accidentally lock the smartcard.

Created attachment 329931 [details]
Patch against 0.8 source: never use keyring when pkinit is used - take 2

pk_userid can also be blank (default), in which case we should not use keyring as well.

Created attachment 330517 [details]
Patch against 0.8 source: avoid bogus debug info by checking use_keyring variable

See:

http://bugzilla.gnome.org/show_bug.cgi?id=567701#c17

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

Looks like no interest upstream. Closing as WONTFIX.