Description of problem: OpenPGP Smart Card (yubikey neo in my case) cannot sign or encrypt email in evolution. Version-Release number of selected component (if applicable): evolution 3.18.3 1.fc23 gnupg 1.4.20 1.fc23 gnupg2 2.1.9 1.fc23 How reproducible: Always Steps to Reproduce: 1. Select openpgp key id in account security settings (correctly shows key) 2. Select PGP Sign in options when composing a new email Actual results: "gpg: skipped "XXXXXXXX": secret key not available gpg: signing failed: secret key not available ", you may need to select different mail options. Expected results: Correctly send pgp signed email. Additional info: Using mutt with crypt_use_gpgme works as expected. Seahorse can sign/encrypt files using the nautilus plugin. Uninstalling gnupg, and ln -s /usr/bin/gpg2 /usr/bin/gpg allows evolution to sign email as expected.
Thanks for a bug report and the investigation. I understood from your investigation that the problem is that gnupg2 cannot access the token properly, thus I'm moving it there. Evolution doesn't do anything special, it only calls the gpg2 or gpg binary to the job for it. Thus you might get a similar result when running the gpg2 from the command line. I reference a related upstream bug report for the evolution-data-server: https://bugzilla.gnome.org/show_bug.cgi?id=759392
No, as I understand the 'Additional info' part from above the issue is with evolution is that it uses gpg-1.x by default and that does not support the smart card. Is that somehow configurable by evolution?
The upstream bug (see comment #1) is for the option to be able to change the gpg binary by a user. Currently, evolution prefers gpg over gpg2, if both are installed. I see I misplaced parameters of the 'ln' command, my fault. I'm moving this to gnupg instead. As it used to work with gnupg too, I guess that's a configuration thing to enable smart card support also in gnupg, no?
There is also an issue with incompatibility of gnupg2 and gnupg key stores which started with the 2.1.x releases. Unfortunately the users need to decide which version they want to run and stick with it.
I don't have any way to help debug this since I don't use evolution or a smartcard. You say it used to work with gpg, which version did it start failing with? Could you try extracting whatever cmdline evolution is trying to use and create a simple test to demonstrate the problem?
The issue turned out to be the different databases in 1.x vs. gnupg 2. After importing the public key and *then* running gpg --card-status signing works as intended (but doesn't use the gnome 3 pinentry). Since I am not actually trying to use gnupg 1, I'll just leave it uninstalled for now. Once the gnupg implementation can be picked in evolution this won't be as much of an issue, but the preference of gpg over gpg2 could still cause database issues. Seahorse appears to use the gnupg 2 database (seahorse-nautilus could encrypt and decrypt), so I was rather confused. I suppose using gpgme would be nicer than explicitly checking for gpg on the path, but this bug is invalid.
Okay, thanks for the explanation. I committed a change in the upstream bug report, see comment #1, yesterday, thus since 3.20.0 users can change which gpg binary should be used. There is no UI for it, but it is intentional. The incompatibility between gpg1 and gpg2 is a problem, but nothing we can do about, I believe.