https://bugzilla.novell.com/show_bug.cgi?id=477488
User vuntz@novell.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=477488#c2
--- Comment #2 from Vincent Untz
It is very unlikely that we will ever do that: The result is a far too complex thing as that you can manage that with automated tools.
Well, you can do that unconditionally. Eg: common-auth: auth substack common-auth-optional-sufficient-required auth include common-auth-after-success You just need to know which modules to put in common-auth-after-success. I'm sure some other modules could benefit from this.
It does not solve your rationale, too: Independent on where pam_gnome_keyring.so is in the stack: your problem to have the password always in sync will _never_ be fullfilled, even not with substack.
But if it is coming after the modules who check the strength and before the modules only storing the password, the possibility to get out of sync is nearly the same.
Well, "nearly" is the difference. I mean, if ldap is used but the ldap server suddenly goes down, what happens? Also, there are other cases for auth where this would be useful: + the login keyring is created with the first password used the first time the user tries to login. If the user mistypes his password the very first time, then... too bad, the login keyring is lost. + http://bugzilla.gnome.org/show_bug.cgi?id=514862 To make the keyring behaves properly with pam-config, I had to revert this upstream change. I couldn't login with an account with an empty password in openSUSE (empty as in "passwd -d"), but I guess it's a config option somewhere since it works on other distros. And now the keyring will force asking a password. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.