Update

I just realized today as my dad was asking my brother and I about how to increase his online presence and searchability that I hadn't made a post since Election Day. Wow... The main reason is I'm a PhD student trying to finish my dissertation up in time to graduate in August. Here's a quick run down in bullet form of what I've been up to.

• Improving my local OpenStreetMap data. I've traced the two lakes above Hartwell with the Lakewalker plugin to josm and finished Hartwell itself. These are enormous lakes! I've also added data for the Appalachian Trail from the beginning to about Knoxville, TN, more to come I'm sure.


• Writing and researching are my two main daily tasks. Hopefully in the near future we can add measuring to that list.


• February 3rd I gave a very long presentation on Seahorse at the CLUG meeting. We're having a key signing party at next week's meeting along with a gent from Fedora who is bringing a couple of XO laptops. If you're in the Clemson area next Tues, stop on by.


• Sporadically working out.

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.