Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 212405 - app-crypt/gpa can't send keys to a keyserver with gnupg2
Summary: app-crypt/gpa can't send keys to a keyserver with gnupg2
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: High normal (vote)
Assignee: Crypto team [DISABLED]
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-03-05 18:17 UTC by Mario Lenz
Modified: 2008-09-01 14:18 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
Fixed ebuild. (gnupg-2.0.9.ebuild,2.46 KB, text/plain)
2008-08-19 22:54 UTC, Kristoffer
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mario Lenz 2008-03-05 18:17:30 UTC
app-crypt/gpa can't send keys to a keyserver with gnupg2.

Reproducible: Always

Steps to Reproduce:
1. emerge gnupg2 and gpa
2. unmerge gnupg if installed
3. send a key from your keyring to a keyserver (protocol hkp)

Actual Results:  
gpa complains about a missing plugin for hkp

Expected Results:  
Well: Send the key to a keyserver, of course :-)

To me, it looks like GPA can't find gpgkeys_hkp (which doesn't exist) if gnupg isn't installed. But there's a file /usr/libexec/gpg2keys_hkp. After:

cp -p /usr/libexec/gpg2keys_hkp /usr/libexec/gnupg/gpgkeys_hkp

everything works. I don't know if this a problem of GPA itself or Gentoo specific, but a quick hack to solve this might be a link

/usr/libexec/gnupg/gpgkeys_hkp -> /usr/libexec/gpg2keys_hkp

created by gnupg2.
Comment 1 Alon Bar-Lev (RETIRED) gentoo-dev 2008-03-06 07:21:52 UTC
Thanks!
Comment 2 Kristoffer 2008-08-19 22:54:21 UTC
Created attachment 163334 [details]
Fixed ebuild.

This isn't fixed as of ebuilds gpg-2.0.9 and gpa-0.7.6, so IMHO this bug should be reopened (but the fix is trivial).

Right now gpg will install the "plugins" (gpgkeys_hkp et al) into /usr/libexec, but gpa will look for them in ${libexecdir}/gnupg. So we can't use the --libexecdir conf flag in gpa to set this to something that works, since it will always look for the gnupg sub directory.

I guess the way to go here is to make the gpg ebuild install the plugins into /usr/libexec/gnupg. I've attached an ebuild which does this, and I've confirmed that gpa can use keyservers after re-installing gpg using this ebuild. Don't know if this breaks assumptions made by other packages using gpg plugins though.
Comment 3 Daniel Black (RETIRED) gentoo-dev 2008-09-01 14:18:52 UTC
corrected this by modifing the gpa ebuild. you'll need to remerge this get the benefit.

the fix wasn't quite as trivial. The assumption about moving the plugins around isn't something i wanted to playwith/test extensively on.

It seemed to only do detection if you emerged gnupg with ldap.

fedora and gentoo both install to /usr/libexec. Suse/debian install to /usr/lib/gnupg/. Not sure which distro uses /usr/libexec/gnupg for the helpers (though it makes a lot of sence to me).

As such i've left the path as /usr/libexec and coded this into gpa.

The svn copy of gpa contains some major rework so next release should be smoother.

Sorry for the delay. Tell me if there is still problems.