GNOME Bugzilla – Bug 620761
pam_gnome_keyring should check if user password unlocks SSH keys
Last modified: 2012-03-15 21:27:11 UTC
I currently use pam_ssh. I'd love to just let gnome-keyring handle this functionality, since it means more automatic configuration and one less daemon. For this to work more automatically, it would help if pam_gnome_keyring could check if the user password unlocks the user's SSH keys, rather than just unlocking the login keyring. If it does, then go ahead and load those SSH keys into gnome-keyring's SSH agent. That would make the gnome-keyring SSH agent precisely as automatic as pam_ssh, rather than requiring an extra password prompt per key the first time I use ssh. It would also avoid storing my login password in the keyring, which seems like a good thing to avoid if possible.
Updating version; this bug still applies to gnome-keyring 3.0.
Sorry that nobody's had time to work on this yet.
Would you have time to work on a patch for this enhancement?
I would, but once I switched to an encrypted disk, I started using GDM autologin, so I no longer enter a login password for pam_gnome_keyring to use when unlocking my SSH key.
Alright, then I'll close this bug (at least for now). I'm trying to change gnome-keyring bugzilla so it tracks actual work/bugs, rather than enhancement plans and ideas. Discussion of enhancements are better suited for gnome-keyring-list@gnome.org until someone is ready to start implementation.
(In reply to comment #5) > Alright, then I'll close this bug (at least for now). > > I'm trying to change gnome-keyring bugzilla so it tracks actual work/bugs, > rather than enhancement plans and ideas. Discussion of enhancements are better > suited for gnome-keyring-list@gnome.org until someone is ready to start > implementation. Couldn't you just create a search for gnome-keyring bugs that filters out bugs of severity "enhancement"? It helps to have some place to track enhancement proposals (and to consolidate duplicates, track dependencies to and from other subsystems, and otherwise take advantage of bugzilla's features). Furthermore, dropping enhancement requests from bugzilla makes life harder for distributions attempting to forward issues from their own bug trackers. More generally, if you intend to respond to all future enhancement requests in bugzilla by summarily closing them if the submitter doesn't provide a patch, that seems like a rather unfriendly response to future users, not to mention an unusual one that doesn't match the conventions and expectations of bugzilla. That said, you could most certainly steer in-depth *discussion* of such features to a mailing list, which does indeed work better than Bugzilla in many cases. Please don't close the corresponding bugs, though.
That's certainly a valid opinion. I hope I can explain my opinion on this clearly as well. (In reply to comment #6) > Couldn't you just create a search for gnome-keyring bugs that filters out bugs > of severity "enhancement"? It helps to have some place to track enhancement > proposals (and to consolidate duplicates, track dependencies to and from other > subsystems, and otherwise take advantage of bugzilla's features). Similarly, a search could be created for enhancement requests that are resolved as 'incomplete'. That is, those without enough interest to gain a contributor to drive them forward. > Furthermore, > dropping enhancement requests from bugzilla makes life harder for distributions > attempting to forward issues from their own bug trackers. Forwarding bugs upstream is wonderful. Forwarding enhancement requests upstream with just a link and no discussion, contribution interest, patches or anything like that ... not so wonderful. Obviously that's not the case with your idea here. It wasn't forwarded upstream, but I figured it was worth mentioning this anyway... > More generally, if you intend to respond to all future enhancement requests in > bugzilla by summarily closing them if the submitter doesn't provide a patch, > that seems like a rather unfriendly response to future users, not to mention an > unusual one that doesn't match the conventions and expectations of bugzilla. No, I don't plan on doing that. I only plan on doing that if after a long time the reporter hasn't managed to take action to invest in the idea themselves, or managed to attract someone else to invest in it. In the case of this patch, I realize multiple years hadn't passed, and that's why I specifically asked if you were interested on working on pushing this idea forward. I agree that it certainly feels nice to be able to go up to an open source project and place your ideas in a form and sit back and imagine that one day they'll show up all nice and shiny in the project. And that would be a great reality indeed. I would love it if there was a team of developers developing gnome-keyring ready to work on good ideas. And perhaps there are some projects can offer that. The reality is that this just doesn't happen. Most of these ideas without anyone invested in them will just sit here. And so it's far better to have bugzilla match reality, than give a false impression and disappointment. In all walks of life: Someone needs to be pushing an idea through to reality for it to go anywhere. An idea on its own is inert. What I'm really interested in is contributors to gnome-keyring, and I'd like to create an atmosphere here in the gnome-keyring bugzilla where it's easy to spot the ideas that someone is willing to contribute to, rather than the (me) feeling inundated and not being able to see the ideas that have a chance (ie: a contributor or investor) and those that will just sit here. Please do again note that I'm not deleting these, and certainly not marking them as wontfix. I'm also not closing all enhancement requests immediately or summarily. You are welcome to reopen these enhancement bugs once they're ready to further.
Fair enough. Closing enhancements after a long period of inactivity doesn't cause the same problems as closing them immediately; thanks for clarifying.