Comment 5 for bug 884856

Ok, it seems I misunderstood the gnome-keyring-daemon startup procedure. Apparently --daemonize --login spawns kind of an empty shell for the functionality (accepting the password through PAM) but does not actually initialize any functionality. For that additional calls the gnome-keyring-daemon with the options --start --components=… (listing the desired component or components) are necessary. As such the PAM module call is actually correct and the fault for gnome-keyring-daemon uncontrollably taking over GPG functions lies elsewhere. (It's just rather confusing because the later calls to --start --components don't leave any traces and looking at the running process list will only show one gnome-keyring-daemon process with --daemonize --login.)

In theory, and apparently in some practical cases as evidenced by comment 4 and some other hints on the web, the modules should be started by the session and selectable in gnome-session-properties. However, that doesn't seem to be the case, for Oneiric at least: I tried creating a new user account on my system, and tried a friend's installation (to exclude the possibility of something being wrong with my installation): There is no entry for any gnome-keyring-daemon module in the startup programs list.

Instead, there are multiple /etc/xdg/autostart/gnome-keyring-….desktop files, one each for gpg, secrets, pkcs11 and ssh with no obvious UI to disable any of them.
WORKAROUND: Removing the /etc/xdg/autostart/gnome-keyring-gpg.desktop file releases (after logging out and in again) gnome-keyring-daemon's grip over the GPG agent functionality and lets gpg and gpgsm work normally again.

-- Steps to reproduce --
1. On a normal Ubuntu Oneiric installation log in normally.
2. Open a Terminal
3. echo $GPG_AGENT_INFO

-- Actual results --
/tmp/keyring-<some random string>/gpg:0:1

-- Expected results (and actual results after applying workaround) --
/tmp/gpg-<random string>/S.gpg-agent:<random number>:1