csh

Pass Says I Have No Secret Key

A while ago, I moved to another GNU+Linux distribution and took my files with me. I put all my important files in a tarball and extracted them onto the new system in their respective places. Someone said moving my GPG dir could be the problem.

I'm new to Pass. Before switching to it, I used Vault to generate my passwords. In fact, all my current passwords are still generated by it. But, I put them in Pass too. So, I'm not losing anything by using Pass... yet. That said, I'd still like to fix the problem before it becomes serious.

Note: my private key does work in both Evolution and the plain command line interface to GPG.

I went to #pass on Freenode. Demure linked to the GnuPG wiki, which gave the following solution:

sudo dpkg-divert --local --rename \
                 --divert /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable \
                 --add /etc/xdg/autostart/gnome-keyring-gpg.desktop

Result:

Adding 'local diversion of /etc/xdg/autostart/gnome-keyring-gpg.desktop to /etc/xdg/autostart/gnome-keyring-gpg.desktop-disable'

Even after this, I still get the same error:

cal@leela:~$ pass show freepo.st
gpg: WARNING: unsafe permissions on homedir '/home/cal/.gnupg'
gpg: decryption failed: No secret key

mitfree asked about the file permissions on my GPG directory, to see if that was the problem.

cal@leela:~$ vdir ~/.gnupg  
lrwxrwxrwx 1 cal cal 20 Oct 25 23:24 /home/cal/.gnupg -> Stow/CRITICAL/.gnupg

He said this was not safe.

I can see why. Ubuntu lets users see each other's files by default, except for a few known important dirs like mail and SSH. If I had multiple users on this system, I'd be in trouble.

mitfree linked to a superuser.com thread about fixing the file permissions on the GPG directory. The following commands were done.

chown -R $(whoami) ~/.gnupg/
chmod 600 ~/.gnupg/*
chmod 700 ~/.gnupg

They completed without error. The permission warning went away, but decryption still failed.

Addition: Actually vdir showed that the unix rights on a symbolic link (or short "symlink") are lrwxrwxrwx. This is perfectly normal for the link itself. More important would have been the output for the target directory, in this case Stow/CRITICAL/.gnupg.
However, running chown on the symlink actually changes the rights for the target, so the fixed worked in this case, but usually using the real path might be a better idea.

holgersson