Bug 1295016

Summary:	OpenPGP Smart Card Cannot be used to sign/encrypt
Product:	[Fedora] Fedora	Reporter:	Evan McClain <aeroevan>
Component:	gnupg	Assignee:	Brian Lane <bcl>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	23	CC:	bcl, jamielinux, lucilanga, mbarnes, mcrha, rdieter, tmraz, tpopela
Target Milestone:	---
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-01-20 04:26:51 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Evan McClain 2015-12-31 22:00:06 UTC

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 17:10:04 UTC

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 17:23:06 UTC

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 17:37:31 UTC

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 17:46:23 UTC

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 17:59:44 UTC

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-20 04:26:51 UTC

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 10:16:39 UTC

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.