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.
holgersson
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.