I think is better to use the freedesktop directory specification.

See http://live.gnome.org/GnomeGoals/XDGConfigFolders

Thanks for this patch. Sorry for not looking at it earlier. This patch is against an old version of gnome-keyring, and is no longer relevant. Could you prepare a new patch?

In the future we'd certainly like to use the XDG folders. This will probably done at a point in time when we update the keyring format, and break forwards compatibility in one of the releases.

Hi, from what i can see in the source this bug seems to be fixed.

Can someone confirm and close this bug?

There's a new backend module that stores stuff in XDG directories, but it isn't yet complete, and the old one is still in use.

Looks like I missed that. It looks like there is still mention of .gnome2 in:

pkcs11/secret-store/gkm-secret-module.c
pkcs11/gnome2-store/gkm-gnome2-module.c
and daemon/dbus/gkd-secret-service.c

Wouldn't it be possible to just replace the calls to g_get_home_dir() with some calls to g_get_user_data_dir() at these three locations? Or do you plan to use the new backend module you mentioned?

Planning on using a new backend module. In addition some of teh old file formats are old and crufty and hard to support new features on. So as part of the migration to the new directory, the new file formats need to be completed.

Hello Stef, what is the status of this? Could you link here the blocker bugs to fix this one?

Any chance this gets fixed for 3.4?

Is this an emergency or problem for users? If so we could rush in a fix for the keyring files.

But I'm hesitant to do this without knowing what the new keyring file format and migration plan is going to look like: bug #672155

I didnt know about #672155. I agree it should be fixed first. So no need to rush this.  It would just be nice to get rid of the remaining items in .gnome2 so users get a more cleaned up and consistent home folder.

Hey Stef, it would be sooo great to fix this :) We want to run Sugar under GNOME in a jhbuild session and for that it would be great to specify an alternative path for the keyring so we don't conflict with the GNOME one. Using the XDg folders would be just great.

Created attachment 220918 [details] [review]
Use the XDG directories for storing keys

Here's a patch which uses g_get_user_data_dir(). If the old 
~/.gnome2/keyrings directories exist on the system, then they are
used exclusively. So new accounts will use the XDG dir.

Are we sure that g_get_user_data_dir() is the right one? It uses
$XDG_DATA_HOME, which according to the spec (and glib documentation)
looks like the location for application data (ie: icons, interface 
etc.) not necessarily user data/databases. However given the state
of ~/.local/share on my system, it seems to have been coopted for
the latter.

Created attachment 220972 [details] [review]
Use the XDG directories for storing keys

 * If the old .gnome2/keyrings exists, then continue to use that
 * Otherwise create the new directory in g_get_user_data_dir() as
   appropriate.

Created attachment 221338 [details] [review]
Use the XDG directories for storing keys

Need to fine tune the logic here, because there can be cases where
the old ~/.gnome2/keyrings directory can be created unconditionally
(ie: by old versions of gnome-keyring sharing a home directory)
in an account that otherwise uses the new XDG based location.

So:

 * If the new XDG directory doesn't exist, and the old
   ~/.gnome2/keyrings does exist, then continue to use that
 * Otherwise create the new directory in g_get_user_data_dir() as
   appropriate.

Well, nobody has stepped up to review or test this yet. But I've been
testing it, and after fixing the logic, it seems to work well.

Normally I would wait until the people requesting the feature take the
time to test it and make sure it works. But in this case maybe we can
get more testing by merging it in and including it in the next unstable
release.

Attachment 221338 [details] pushed as 747b37b - Use the XDG directories for storing keys

This is not properly fixed as of version 3.12.0.  The XDG Base Directory specification states that user data should be located in XDG_DATA_HOME, with a default value of ~/.local/share.  On my Arch Linux system, I have set that environment variable, but gnome-keyring is still using the default location.

$ grep XDG_DATA_HOME= /etc/profile.d/custom.sh 
export XDG_DATA_HOME="${HOME}/.xdg/data"
$ echo ${XDG_DATA_HOME}
/home/carl/.xdg/data
$ ls ~/.xdg/data/keyrings
ls: cannot access /home/carl/.xdg/data/keyrings: No such file or directory
$ ls ~/.local/share/keyrings
login.keyring  user.keystore

Please re-open this bug.

You may want to check the environment of gnome-keyring-daemon to see if it has XDG_DATA_HOME set. See /proc/xxx/environ.

gnome-keyring is started way early in the login process, before your script will be run. I'd recommend putting

XDG_DATA_HOME=${HOME}/.xdg/data

in /etc/environment instead (or don't override it at all and stick with the defaults unless you have a really good reason to change it)

As suspected, /proc/xxx/environ for the keyring daemon's pid did not reflect my variable.  I tried moving it to /etc/environment, but that pam files does not support variable expansion, so the variable does not expand ${HOME}.  I was finally able to correct this by moving my XDG variables from /etc/profile.d/custom.sh to ~/.pam_environment, with hard-coded paths.

$ cat .pam_environment
XDG_CONFIG_HOME=/home/carl/.xdg/config
XDG_CACHE_HOME=/home/carl/.xdg/cache
XDG_DATA_HOME=/home/carl/.xdg/data

Gnome-keyring is now placing data at /home/carl/.xdg/data/keyrings as desired.  Thanks for tips Stef and Ray!