In response:

I received a couple of comments regarding my last post on Seahorse's GNOME Keyring integration and would like to respond to them here so everyone not following the comments on my posts can see them. :P

Étienne: I would suppose this would depend on how you changed your session/login password if you did it via the About Me control applet, it could probably be modified to change the keyring password as well. I'm not sure how secure entries would be implemented for it without copying code though, perhaps with GNOME keyring's new secure memory API?

Esteban:
- What about thinkfinger integration? It seems like about some of gnome password dialogs support this (gdm,console), some do in a broken way (gksudo) and others don't (keyring manager, gnome-screensaver).

This might be useful but would need to be implemented on the gnome-keyring end. Luckily gnome-keyring is just a generic secret store and can do many such things. Also, I would imagine hardware for testing would be required.

- Why doesn't gnome-keyring just use your user password as the master password? Or, why can't gnome-keyring store my user password and my sudo password? One way or the other would seem more unified and consistent.

gnome-keyring can't simply use your user password unless you enter it as your master password because as a user, you don't have access to the hash of your system password stored in /etc/shadow. Étienne's comment mentioned libpam-keyring, but it's my understanding that you still have to originally set gnome-keyring to use your session password. Although now you should be able to get around the problem mentioned at the libpam-keyring site of not being able to change your keyring password. I suppose gnome-keyring could store your sudo password but I'm not sure that would be advisable (i.e. you might as well always run as root). This would probably require a patch to gksudo/whichever graphical auth library you're using for privilege escalation.

- It would be nice if gnome-keyring had some notion of "important" passwords vs everything else so that it can just go ahead and fill in the right values when I don't care sort of like firefox does when it doesn't have a master password set. Something in between where on a per password basis I can say "Always ask for master" would be cool.

This might be where an editor is needed to be able to set/unset the application access permissions. Right now if you select 'Always Allow' or 'Deny' there's no way to change that.

- Firefox and other apps integration: Firefox reimplements exactly the same functionality. Could gnome-keyring be swapped out in the gnome native builds like they have done for print and file dialogs?

I'm not sure about Firefox, but possibly Epiphany. There are some thoughts on that on l.g.o.

Seahorse - GNOME Keyring Integration

For all of you that have set your GNOME Keyring master password and long to change it, long no more! This previously missing functionality is now available in the 2.19.4 release of Seahorse. The text entries are "secure" in that your passwords will never be paged out of memory onto the disk and with recent upgrades to gnome-keyring itself, they shouldn't be paged out there either (development branch only). Here's what the tab in the Encryption Preferences control applet looks like upon a successful change:

Behold the power of GNOME!

I'm a little bit behind on my /. reading, but today I noticed an article published Monday about the FireGPG extension for Firefox.

You may be thinking, "This news sounds familiar" and you'd be right sort of. That's right, if you've been using Epiphany and Seahorse, this functionality has been available since September in development versions. That's a good 6 months before a similar extension was available for FF. Behold the power of GNOME!

I wonder if they have a similar problem with GMail inserting <cr> or <lf> into text they want to verify?

Also for the keen observer, check out the FireGPG icon they included in the URL bar: Yep, that's the icon Seahorse provides for use in the GNOME menus and as our window icon. Hooray reuse! I wonder if they could use our DBus API if it's available?

Also, currently we don't have icons for the context menu items in our extension (I'm not sure FireGPG's are the most appropriate for this) but if anyone has icon ideas or better yet icons ;) you know where to put them.