Bug 1295016 - OpenPGP Smart Card Cannot be used to sign/encrypt
OpenPGP Smart Card Cannot be used to sign/encrypt
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: gnupg (Show other bugs)
23
x86_64 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Brian Lane
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-31 17:00 EST by Evan McClain
Modified: 2016-01-20 05:16 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-19 23:26:51 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Evan McClain 2015-12-31 17:00:06 EST
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.
Comment 1 Milan Crha 2016-01-19 12:10:04 EST
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
Comment 2 Tomas Mraz 2016-01-19 12:23:06 EST
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?
Comment 3 Milan Crha 2016-01-19 12:37:31 EST
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?
Comment 4 Tomas Mraz 2016-01-19 12:46:23 EST
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.
Comment 5 Brian Lane 2016-01-19 12:59:44 EST
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?
Comment 6 Evan McClain 2016-01-19 23:26:51 EST
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.
Comment 7 Milan Crha 2016-01-20 05:16:39 EST
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.

Note You need to log in before you can comment on or make changes to this bug.