I can't tell if this should be considered a configuration / deployment bug, or if it should be considered a code bug. https://wiki.archlinux.org/index.php/GNOME_Keyring#With_a_display_manager Arch's wiki indicates that this is a known problem, but I haven't found any information on the SDDM bug tracker to confirm. Essentially, SDDM doesn't unlock the keyring when the user logs in, even if the users password matches the keyring, and all that other fun stuff. Other desktop environments do, such as Gnome, LightDM, etc.
scroll down six lines.
I think that, perhaps, you misunderstood what I was posting a bug report about. This is my failing, as I should have been more clear about what I was saying in my initial report. SDDM doesn't behave the way the majority of other desktop managers do, and unlock the keyring automatically. This violates the principal of least surprise. A user will expect any desktop manager to automatically do this with the default configuration. By not doing it, the user will be surprised. This is a feature request to automatically cause SDDM to unlock the keyring out of the box, without requiring the user / admin of a system to muck with PAM. Either 1) Gentoo needs to adjust the way SDDM is deployed, so as to add the appropriate configuration so that the gnome keyring is unlocked automatically, like most users will expect. (Obviously, a USE flag would be an appropriate way to address this.) or 2) SDDM code needs to be modified such that it doesn't require PAM configuration to be modified. Possibly this would be a configure script option, so that the existing behavior could be preserved for the (in my opinion) rare user who does not want their keyring unlocked. Obviously, the vast majority of people on bugs.gentoo.org are volunteers, so please don't think I'm demanding or expecting anything. I'm simply posting a bug so that this issue can be tracked until (or unless) resolved. I, personally, strongly feel that this is a bug, and an obvious bug. Perhaps others don't feel like it's "broken", and that's why I reported this as an enhancement request instead of a bug directly. Please don't mark the bug invalid unless you're very convinced that SDDM should never (either because of the ebuild deploying the configuration changes, or SDDM 's code is modified so that it does it itself) automatically unlock the gnome keyring until an admin makes configuration file changes. I think this is a very debatable point, and I suspect that there are many users and admins that use SDDM on gentoo who would like to see this work automatically. I may be able to write an ebuild patch that accomplishes this behavior, but (like everyone else) can't guarantee that I'll be able to prioritize doing that over the other things I have going on, so I guess we'll just have to see. Thanks :-)
I personally believe that this feature is unnecessary and will lead to confusing interaction between the layers. (e.g. "why does my keyring work via sddm but not via startx", etc) I believe that the best way to implement what you are discussing is to simply put an einfo in the pkg_postinst of gnome-keyring, as it is generally Gentoo convention not to muck around with user configuration files.
I don't know what is wrong with SDDM. Keyring unlocking is done with the PAM session which is handled by sys-auth/pambase[gnome-keyring] in Gentoo. SDDM appears to define a pam file pointing to system-login which takes care of that.
Switching assignee as I don't believe there is any action required by the Gnome team here.
Please test latest version 0.16.0-r2. It has a new line -session optional pam_gnome_keyring.so auto_start so in theory it should work.
