| Summary: | app-crypt/gnupg: gpg-agent calls pinentry symlink which does not link to binary | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | MickKi <confabulate> |
| Component: | Current packages | Assignee: | Crypto team [DISABLED] <crypto+disabled> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 10.1 | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | app-crypt:gnupg-2.0.14:20100204-090929.log-20100211 | ||
|
Description
MickKi
2010-02-26 06:49:23 UTC
Did you check if it works, if you pass pinentry name explicitly ? Cause gpg-agent does call 'pinentry' by default. Attach build log of gnupg. (In reply to comment #1) > Did you check if it works, if you pass pinentry name > explicitly ? Cause gpg-agent does call 'pinentry' by default. Hmm ... perhaps something is amiss with my system. Calling pinentry when launching gpg-agent does not work, the socket that gpg calls thereafter is different to the one that gpg-agent is listening to *and* pinentry fails to launch: ======================================== $ gpg-agent --daemon --no-detach --pinentry-program '/usr/bin/pinentry' --debug-level guru --log-file gpg-agent.log gpg-agent[2628]: enabled debug flags: command mpi crypto memory cache memstat hashing assuan GPG_AGENT_INFO=/tmp/gpg-kx8NJ7/S.gpg-agent:2629:1; export GPG_AGENT_INFO; ======================================== The log shows: ======================================== 2010-02-25 06:48:32 gpg-agent[6741] DBG: ... miss 2010-02-25 06:48:32 gpg-agent[6741] starting a new PIN Entry gpg-agent[6741]: can't connect server: `ERR 67109133 can't exec `/usr/bin/pinentry-qt': No such file or directory' 2010-02-25 06:48:32 gpg-agent[6741] can't connect to the PIN entry module: IPC connect call failed 2010-02-25 06:48:32 gpg-agent[6741] command get_passphrase failed: No pinentry gpg-agent[6741.7] DBG: -> ERR 67108949 No pinentry <GPG Agent> gpg-agent[6741.7] DBG: <- [EOF] ======================================== This is what my ~/.gnupg/gpg-agent.conf contains: ======================================== # GPGConf disabled this option here at Wed Sep 6 22:59:55 2006 BST # default-cache-ttl 1800 ###+++--- GPGConf ---+++### pinentry-program /usr/bin/pinentry-qt no-grab quiet verbose default-cache-ttl 3000 debug-level basic log-file socket:///home/michael/.gnupg/log-socket ###+++--- GPGConf ---+++### Sun Feb 21 10:26:31 2010 GMT # GPGConf edited this configuration file. # It will disable options before this marked block, but it will # never change anything below these lines. ======================================== So it seems that instead of calling /usr/bin/pinentry, gpg-agent calls /usr/bin/pinentry-qt. I can fix the symlink manually of course (on both of my machines) but it looks as if that was set up by some GPGconf script? > Attach build log of gnupg. Attachment follows. -- Regards, Mick Created attachment 221347 [details]
app-crypt:gnupg-2.0.14:20100204-090929.log-20100211
app-crypt/gnupg-2.0.14 emerge log file.
For future reference: do not attach such abominations. (AFAICT it's actually tar.gz.gz - yes, twice gziped). If you look at common/homedir.c, you'll see
that, if GNUPG_DEFAULT_PINENTRY is undefined (as it
seems to be the case), it simply calls pinentry.
Any chance you have an old symlink somewhere in your ${PATH} ?
(In reply to comment #5) > If you look at common/homedir.c, you'll see > that, if GNUPG_DEFAULT_PINENTRY is undefined (as it > seems to be the case), it simply calls pinentry. > > Any chance you have an old symlink somewhere in your ${PATH} ? > Apologies for the double-gzipped archive - I didn't realise I'd run it twice. How do I search for the old symlink you mention? I have the same problem on two different machines. On one the symlink from /usr/bin/pinentry is pointing to /usr/bin/pinentry-curses on the other (where I have removed qt3 and provided you the logs) to /usr/bin/pinentry-qt4. I from their age (c. 2007 and 2006 respectively) I assume that these links were created by some gnupg-agent installation or setup script back then. I can't recall to having made these links myself. However, if I am the only one reporting it, then it may not be a problem for more recent installations. I am currently installing Gentoo on a new machine and I will keep an eye on this to see what gets installed. -- Regards, Mick Well, this symlink is created by pinentry itself
- the choice is made by configure script (have a look near the end of
configure.ac). However, as during gnupg build default pinentry
was not overridden, it should run /usr/bin/pinentry.
Any chance you have non-system copy of gnupg somewhere in ${PATH}
or a config file, that sets it to pinentry-qt ?
OK, never mind, I should have read your post properly first - for that matter, so should you. Though usually command line overrides config files, it seems it's different with gnupg. Doesn't this line give you a hint: pinentry-program /usr/bin/pinentry-qt Looks like NOTABUG, unless you count command line not overriding config file as one (I think I would consider it one, but perhaps gnupg has a good reason for it). Thanks for looking into this problem. I think that we have at least two bugs here: 1. The bug that made me raise this report is the fact that gpg stopped working - evidently the symlink in /usr/bin to the new pinentry binary (/usr/bin/pinentry-qt4) was suddenly not there. The ~/.gnupg/gpg-agent.conf file defines the pinentry-program as /usr/bin/pinentry-qt. This is a setting that was set up automatically by some install/configuration script many moons ago on at least two PCs of mine. Well, to be more precise on the second PC the pinentry-program was not set up as pinentry-qt, but as pinentry-curses. So this bug as I see it is that gpg functionality is now broken because the latest updates did not respect this setting, or at least did not raise a warning (as far as I recall) for the user to deal with it. 2. The second bug may be that when I pass: --pinentry-program /usr/bin/pinentry-qt to gpg at the CLI, gpg seems to ignore it. I say that this *may* be a bug because I am not sure if I need to use a particular format for defining this option and as you say gpg may have a good (security related?) reason for not using it. Now, at least 1. above could be due to a legacy setting on my boxen and these days gentoo defaults create the correct symlinks to make sure that gpg-agent continues to function. If this is the case, I agree that this could be seen as NOTABUG - although legacy settings should at least raise a warning. When I finish a new install in the next few days I will look to see what it shows. Either way, I am not sure what pinentry should point to in /usr/bin to make sure that gpg works both on the console and in an Xsession. Can you please show me what ls -la /usr/bin/pinentry* looks like on a default installation - it should help me set up mine correctly. -- Regards, Mick (In reply to comment #9) > 2. The second bug may be that when I pass: > --pinentry-program /usr/bin/pinentry-qt > > to gpg at the CLI, gpg seems to ignore it. INVALID. gpg does NOT take a pinentry argument. Only gpg-agent does. > Can you please > show me what ls -la /usr/bin/pinentry* looks like on a default installation - > it should help me set up mine correctly. Here are two of my systems: $ ls -la /usr/bin/pinentry* lrwxrwxrwx 1 root root 14 Sep 27 17:51 /usr/bin/pinentry -> pinentry-gtk-2 -rwxr-xr-x 1 root root 43968 Sep 27 17:51 /usr/bin/pinentry-curses -rwxr-xr-x 1 root root 98976 Sep 27 17:51 /usr/bin/pinentry-gtk-2 $ ls -la /usr/bin/pinentry* lrwxrwxrwx 1 root root 15 2010-09-27 23:16 /usr/bin/pinentry -> pinentry-curses -rwxr-xr-x 1 root root 48848 2010-09-27 23:16 /usr/bin/pinentry-curses I'm going to close this as WORKSFORME, and just help you fix your system to match everybody else: 1. rm /usr/bin/pinentry* ; emerge -k1 gnupg 2. Fix your configs to not referenced removed files. I'm not sure where that GPGConf block came from, it's not part of the stock install. |
