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
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
|
Details
Description:
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. Installed: * 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 cacert.org) 3. Attempt to import into kleopatra or even using gpgsm directly, like described here: http://www.mew.org/en/feature/smime.html 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
Monday, 29 August 2011, 14:11 GMT
Reason for closing: Won't implement
FS#8783requesting the opposite. :)Kmail works fine with OpenGPG/MIME here. Also IMO your fix is suboptimal.
The announcement of the latest gnupg 1.x version (http://lists.gnupg.org/pipermail/gnupg-announce/2010q4/000303.html) 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?
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:
balsa
basket
centerim
claws-mail
ekg2
gpa
gpg-crypter
gyachi
kdepimlibs
mcabber
mutt
seahorse
> 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...
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.
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.
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...
- 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?
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.
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 ;)
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.
Has anybody found a workaround wrt claws-mail decrypting?
>[...] 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...
@Andrew,
Does claws-mail correctly verifies simply signed messages? Does decryption with gpg --decrypt work?
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));
gpgmegtk_free_passphrase();
gpgme_data_release(plain);
return NULL;
}
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)?
I have got from my respondent an .asc file which starts with:
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>
...
In KGpg (KDE gnupg frontend) I have imported this key and set it trusted/ultimate. I recieve from the respondent messages which start with:
-----BEGIN PGP MESSAGE-----
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).
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.
.asc file starts with ----BEGIN PGP PUBLIC KEY BLOCK----- - why are you saying about private key?
And message body contains pgp-block only.