Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#22110 - [gpgme] get rid of gnupg (1.x) as dependancy

Attached to Project: Arch Linux
Opened by Conrad Hoffmann (conrausch) - Wednesday, 15 December 2010, 12:19 GMT
Last edited by Tobias Powalowski (tpowa) - Monday, 29 August 2011, 14:11 GMT
Task Type Feature Request
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No



gnupg (1.x, as opposed to gnupg2) is pulled in as a dependacy of gpgme. As far as I can tell from a quick attempt, gpgme works just fine w/o gnupg 1.x, as long as gpg2 is installed and the path passed to configure: --with-gpg=/usr/bin/gpg2

I installed Kleopatra and KMail on a fresh system and tried to get both OpenPGP and S/MIME encryption to work. It was close to impossible. While the former worked out of the box, the latter did not and my attempts to get it to work just resulted in OpenPGP not working anymore either.

Turns out, some part of this (gpgconf, maybe called by Kleopatra? I am not sure) rewrites the gnupg config file (~/.gnupg/gnupg.conf) with values specific to gnupg2. Since both versions of gnupg use the same config file, this results in gnupg (1.x) not working anymore. This, in turn, leads to gpgme not working anymore. This, of course, renders the systems encryption infrastructure worthless.

While one could consider the real problem to be some program rewriting the gnupg config file in a fashion incompatible with other software, I think it would be much easier to just ditch gnupg 1.x alltogether. I have successfully solved all my problems by renaming /usr/bin/gpg to /usr/bin/gpg1 and linking /usr/bin/gpg to /usr/bin/gpg2. I recognize the fact there may be some use cases where gpg 1.x is required, but frankly I don't know of any, so I though it would be good idea to collect all arguments in this bug report and then find an appropriate solution.

* extra/gpgme 1.3.0-1
* extra/gnupg2 2.0.16-3
* extra/gnupg 1.4.11-2
* extra/kdepim-kleopatra 4.4.8-1

Steps to reproduce:

1. pacman -S kdepim-kleopatra
2. Get Client Certificate (e.g. from
3. Attempt to import into kleopatra or even using gpgsm directly, like described here:
4. ???

Possible Fix:
1. #> mv /usr/bin/gpg /usr/bin/gpg1
2. #> ln -s /usr/bin/gpg2 /usr/bin/gpg
3. Try same steps as above...

I fought with some other anomalies, e.g. I had to set the pinentry program in the gpg-agent.conf, allthough the agent is called per default with the correct program as parameter, but maybe this wasn't really an issue but just some side effect.
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Monday, 29 August 2011, 14:11 GMT
Reason for closing:  Won't implement
Comment by Greg (dolby) - Thursday, 16 December 2010, 02:33 GMT
FTR i had once opened  FS#8783  requesting the opposite. :)
Kmail works fine with OpenGPG/MIME here. Also IMO your fix is suboptimal.
Comment by Conrad Hoffmann (conrausch) - Thursday, 16 December 2010, 07:57 GMT
While I would totally not deny that my fix suboptimal :) you do not seem to make much of a point here. Like I stated in the report, yes, OpenGPG does work fine out of the box, but not S/MIME, which is something completely different (see and I would be surprised if that worked out of the box for you (but I would love to hear how, if I am wrong!).

The announcement of the latest gnupg 1.x version ( clearly states that gnupg 1.x does not have S/MIME support and that gnupg2 is better suited for the desktop.

Are the any real use cases where gnupg2 is unable to provide the same functionality as gnupg?
Comment by Greg (dolby) - Thursday, 16 December 2010, 10:27 GMT
Sadly no, S/Mime doesnt work for me but my key is an OpenGPG one created with gnupg 1.x.
Does S/Mime work if you remove gnupg 1.x and having only a gpg2 executable?
Maybe it would make sense adding both gnupg implementions as optdepends so the user can choose..
As far as i can see neither the gpgme bin nor libs files link to gnupg or gnupg2 so that could theoretically be done.

Also if using only gpg2 doesnt work, what happens with the rest of the packages using gpgme:
Comment by Allan McRae (Allan) - Thursday, 16 December 2010, 10:38 GMT
Hmmm... this is using a developemental version of pacman which uses gpgme. After removing both gnupg and gnupg2 I get:

> pacman -Syyu
:: Synchronizing package databases...
pacman 1.0K 336.6K/s 00:00:00 [######################] 100%
pacman 0.3K 9.8M/s 00:00:00 [######################] 100%
error: GPGME error: Invalid crypto engine
error: failed to update pacman (gpgme error)

Installing only gnupg2 results in this being still broken. Installing only gnupg fixes the issue. So gnupg2 appears to be the optional dependency...
Comment by Greg (dolby) - Thursday, 16 December 2010, 10:44 GMT
Or it just expects a gpg binary which gnupg2 doesnt provide.
An additional solution besides using optdepends, would be to add conflicts and/or provides gpg to both.
Dont remember how those arrays are used exactly.
Comment by Allan McRae (Allan) - Thursday, 16 December 2010, 10:51 GMT
Ah... making a symlink is indeed enough.

If gnupg2 is a complete replacement for gnupg, we could have the gnupg2 conflict and provide gnupg and have a /usr/bin/gpg symlink. That way, gpgme could depend only on gnupg and if someone wanted gnupg2, that would uninstall gnupg.
Comment by Conrad Hoffmann (conrausch) - Thursday, 16 December 2010, 13:11 GMT
@Allen: This is pretty much what i was thinking of.

Yet, there remains one thing to be checked: in gpgme the path to the gpg executable can be set when calling configure. gpgme will execute the given executable to determine the gnupg version used. There are now two possibilities:

1. gpgme just checks for a certain minimum version, all is well
2. the result of the check influences the behaviour of gpgme other than the path of the binary being used

If the latter is the case this might lead to difficulties if gpgme was compiled against gnupg2 but is being used with gnupg1, whereas the other way around should be no problem. This is just a thought. I have already compiled gpgme against gnupg2 only and I will run some checks and look at the source code. I will report my findings back here.

Yet I am still interested if anybody could point me to a genuine example of gnupg1 being the only option as opposed to gnupg2. The websites mentions easier porting, but I guess this does not really an issue for Archlinux...
Comment by Conrad Hoffmann (conrausch) - Friday, 17 December 2010, 13:00 GMT
This is what it looks like to me:

- gpgme works fine with either version, it just needs to find the executable ath the path hardcoded into the library at compile time
- gpg2 adds some features not present in gpg1 (e.g. s/mime)
- I've read mentions that there are some exotic use cases where gpg2 is not backwards compatible, but nobody ever defines an actual case

So, judging from this summary, my proposal for a solution would be this:

- gnupg and gnupg2 conflict and both provide s/t, e.g. gnupg
- the default should be gnupg2
- packages needing s/mime (e.g. kleopatra) should still eplicitly depend on gnupg2 (is that possible?)
- people not using s/mime can choose to replace gnupg2 with gnupg1 if they wish

This way:

- all off the crypto stuff in KMail, etc. should work out of the box
- no compatibility with other packages would be broken (as far as i can tell)
- choice of gnupg1 is still available

What do you guys think?
Comment by Allan McRae (Allan) - Friday, 17 December 2010, 13:07 GMT
I would prefer gnupg1 to be the default as it is lighter in terms of deps.
Comment by Greg (dolby) - Friday, 17 December 2010, 16:53 GMT
I would prefer not having a default, and treat this the same as java-runtime or phonon-backend.
Both gnupg's providing gnupg. But i think that way pacman will install gnupg1 if you dont have gnupg2 installed.
Also why does kleopatra require S/MIME? I admit not using it much but i dont think its much useful in its current state anyway, i mostly tried to use it in conjuction with konqueror and certificates, not gpg.
Comment by Conrad Hoffmann (conrausch) - Friday, 17 December 2010, 17:22 GMT
Well, i guess that sounds good enough. It stills reflects the state of affairs much better then installing them side by side and will make it much easier to figure out what's wrong if things don't work. It is much more ovious that s/mime won't work if you don't have gnupg2 installed then it is to figure out why gnupg2 isn't used although it is installed.

As for kleopatra, I assume it can actually be used w/o s/mime for key handling, but one would usually use kgpg for this. The main point of Kleopatra is that it can handle certificates (although rather badly, I agree with you :) ). This would also fit nicely with your suggestion: install kleopatra, it will pull in gnupg as dependancy and can handle your keys. Want s/mime support? Install gnupg2. Really makes much more sense this way. Also, you will immediately find the crucial information, i.e. that you need gnupg2 for s/mime, on the web.

So, to make a long story short: I totally second your suggestion, Greg ;)
Comment by Greg (dolby) - Wednesday, 26 January 2011, 14:41 GMT
FWIW distributions like Slackware and Debian, ship gnupg along with gnupg2 retaining the gpg annd gpg2 naming, so i'm not sure the solution proposed above is the appropriate one.
Comment by Greg (dolby) - Friday, 25 March 2011, 07:25 GMT
I have discussed the packaging of the gpg stack a couple of times in IRC. The people involved in the discussions both times, were unfamiliar with packaging, but they all seemed to agree on one thing. The same i mentioned above. The is no compelling reason having both gnupg 1.x and 2.x in the same system. Gnupg 2.x has some additional features over 1.x, so if the user needs those he should prefer that one, like in this case.
So i think my suggestion for both packages to provide gpg and both having a /usr/bin/gpg binary should work.

Since pacman will eventually add signed packages support, i would assume that gnupg 1.x and gpgme will have to move to [core] so this should be solved before that time. Users who need s/mime would need to replace gnupg 1.x with gnupg 2.x on their own. A gpg-agent split package might also be needed, but thats a pacman issue.
Comment by Andrew Gaydenko (student975) - Sunday, 10 April 2011, 04:46 GMT
It seems I'm next affected with the issue: with claws-mail I can not decrypt messages (and it is a showstopper wrt claws-mail for me) - that "No data" error. The trick with renaming /usr/bin/gpg an soft-linking /usr/bin/gpg2 doesn't help.

Has anybody found a workaround wrt claws-mail decrypting?
Comment by Leonid Isaev (lisaev) - Sunday, 10 April 2011, 19:48 GMT
>[...] rewrites the gnupg config file (~/.gnupg/gnupg.conf) with values specific to gnupg2.
That can't happen.
> Since both versions >of gnupg use the same config file [...]
From the manpage "If you need to use different configuration files, you should make use of something like ‘gpg.conf-2’instead of just ‘gpg.conf’." So, the problem seems to be in your KMail setup...

Does claws-mail correctly verifies simply signed messages? Does decryption with gpg --decrypt work?
Comment by Andrew Gaydenko (student975) - Sunday, 10 April 2011, 20:07 GMT
'gpg --decrypt' does work (as well as gpg2).

As for 'simply signed' message - sorry, I don't understand this technical detail. I have imported .asc key (making it trusted/ultimate), and in KMail I just read encrypted messages transparently (they are decorated with light-light-green background in KMail) without any password entering.

"No data" error in Claws-Mail rises here (starting from sgpgme.c:429, v.3.7.9):

if (gpgme_get_protocol(ctx) == GPGME_PROTOCOL_OpenPGP) {
err = gpgme_op_decrypt_verify(ctx, cipher, plain);
if (err != GPG_ERR_NO_ERROR) {
debug_print("can't decrypt (%s)\n", gpgme_strerror(err));
privacy_set_error("%s", gpgme_strerror(err));
return NULL;
Comment by Leonid Isaev (lisaev) - Sunday, 10 April 2011, 20:20 GMT
Hmm... maybe I misunderstand something here, but what do you mean by "imported .asc key". You decrypt with your private key, right? It is the encryption, which proceeds with a public key...

Please try sending (in claws) a mail to yourself, encrypting it with your public key. The message should decrypt, if your private key is in place.

Also, which plugins does claws show (in Configuration/Plugins)?
Comment by Andrew Gaydenko (student975) - Sunday, 10 April 2011, 20:31 GMT

I have got from my respondent an .asc file which starts with:

Version: PGPfreeware 6.5.8 for non-commercial use <>

In KGpg (KDE gnupg frontend) I have imported this key and set it trusted/ultimate. I recieve from the respondent messages which start with:

Version: GnuPG 1.5.8

These messages are transparently decrypted in KMail (rather in Claws-Mail). I have not generated any keys and don't encrypt messages myself (and, frankly speaking, don't understand all these technical details related to PGP).
Comment by Leonid Isaev (lisaev) - Sunday, 10 April 2011, 21:00 GMT
OK, in a nutshell: If A and B have to establish a secure mail communication, each of them generates a keypair, which includes a public and private key. They publish their *public* keys somewhere on WWW, but keep private ones. If A wants to send an encrypted message to B, she does "gpg/gpg2 --encrypt --recipient B /path/to/file". This is encrypted with B's public key, which is usually available online, but can only be decrypted with B's private key. Please see <> for details.

Hence my question... your peer must be nuts, if he gave you his/her private key. Most likely it is the *public key*. Then, we are talking about a signed message, not encrypted one.

Comment by Andrew Gaydenko (student975) - Sunday, 10 April 2011, 21:09 GMT

.asc file starts with ----BEGIN PGP PUBLIC KEY BLOCK----- - why are you saying about private key?
And message body contains pgp-block only.
Comment by Leonid Isaev (lisaev) - Sunday, 10 April 2011, 21:30 GMT
OK, this discussion becomes too long and off-topic... Let's take it to your forum post.
Comment by Tobias Powalowski (tpowa) - Monday, 29 August 2011, 14:11 GMT
Ok we let it as it is.