I have the following in my .bashrc file: keychain XXXXX123 id_rsa The ssh key loads fine. I am prompted for my passphrase. When keychain comes to load the gpg key, it just hangs. I get no passphrase entry dialog. Looking at the process list, I see pinentry has been started, but strace says it is doing nothing. The only was to resolve the situation is to killall -9 pinentry (without -9 it does nothing), and THEN I am prompted to enter my passphrase. Reproducible: Always If I remove the ssh part from the .bashrc keychain line I get the same result.
Works for me. Which pinentry do you use? There are several available based on USE flag and pinentry being a symlink to one them.
Apparently I use pinentry-gtk-2, and today I need two killall -9 pinentry commands to get it working, not just one. [ebuild R ] app-crypt/pinentry-0.7.3 USE="gtk ncurses -caps -qt3" 0 kB
Just to be clear: it only hangs when the gpg key is not cached or if the cache time has expired (I'm not sure how to make it not expire). Changing the symlink to pinentry-curses does not help.
Which version of gnupg do you use? I'm having gpg-agent problems with app-crypt/gnupg-2.0.8.
app-crypt/gnupg-2.0.7
keychain-2.6.8 works correctly, please try it out.
Please reopen if you have further issues with this one.
It worked for a while, but now I have the same problem again. I think the gpg passphrase expiry is causing the problem - how can I turn it off to test this?
Please provide sequence for me to reproduce this.
$ tail -n 4 .bashrc keychain id_rsa GPG1111 source $HOME/.keychain/$(hostname)-sh source $HOME/.keychain/$(hostname)-sh-gpg I am then using gnome-terminal. It prompts me for my password. It works. I open a new tab. It works. A few days later it stops working..
DAYS?!?!?! Please try to play with small values with these variables of ~/.gnupg/gpg-agent.conf default-cache-ttl default-cache-ttl-ssh max-cache-ttl max-passphrase-days And reproduce this in shorter times.
I have removed all ttl options from my config file for the moment, and killed ssh-agent and gpg-agent. I closed all terminals, and opened one. I was prompted for my ssh passphrase and my gpg passphrase. I then closed the terminal. I opened another terminal, was not prompted for anything, then typed: gpg -d file.txt and I was prompted for my gpg passphrase again.
I rebooted a few hours ago. Already, I see this: * Adding 1 gpg key(s)... (hang) If I type killall -9 pinentry ; killall -9 pinentry then it will prompt me. But keychain doesn't seem to work with gpg very well. ssh keys work fine.
Please try to reproduce using latest versions.
days -> ~4 hours. Will do.
Please report back when this still happens.
Hi, I've exactly the same problem with gnupg-2.0.13, pinentry-0.7.6 and keychain-2.7.0 . I'm using pinentry-curses
(In reply to comment #16) > Please report back when this still happens. > I have whatseems to be the same problem. Using keychain to cache ssh keys works fine, but when keychain tries to add my gpg key, it hangs. Issuing a 'killall -9 pinentry' lets it continue; it then gives an apparently curses-based password input dialog, and all is well. This is with versions: app-crypt/gnupg-2.0.14 app-crypt/pinentry-0.7.5 net-misc/keychain-2.7.0 .
I was running gnupg-2.0.11 with keychain and pinentry-curses with no problems. On my x86 machine, the upgrade to gnupg-2.0.14 introduces a pinentry error when keychain runs: Error: Problem adding gpg key (is pinentry installed?) ... Masking off gnupg-2.0.14 and running gnupg-2.0.11 fixes the issue.
Downgrading to gnupg-2.0.11 solves the problem for me as well.
I have this problem as well; I'm using curses pinentry. I launch keychain and source the generated files from ~/.bashrc, as most do. This problem started for me within the last few weeks. keychain-2.7.0 gnupg-2.0.14 On a completely fresh reboot, first time terminal use, I enter my ssh passphrases, and then it pauses. I killall -9 pinentry, and /then/ the curses dialogue starts, I enter it, and things seem to progress normally. A very nasty sideeffect is that if you Control-C at the pause, then pinentry is still running in the background. One you get a few of those running, loadavg goes through the roof. Downgraded to 2.0.11 (.12 and .13 ~key'd); things now work as they used to. As opposed to some on here, this problem always happens, and allows happens immediately for me -- no waiting at all.
I think the bug is due to not settings the GPG_TTY environment variable before calling gpg.
Created attachment 227437 [details, diff] Patch for keychain 2.7.0 I have added the GPG_TTY environment variable before calling gpg. it seems to fix the bug.
(In reply to comment #23) > Created an attachment (id=227437) [details] > Patch for keychain 1.7.0 > > I have added the GPG_TTY environment variable before calling gpg. it seems to > fix the bug. > After patching keychain, the bug is also fixed on my system (gnupg-2.0.14, pinentry-0.7.6 and keychain-2.7.0). Thanks!
I have committed this fix to funtoo github for keychain and it will be in version 2.7.1 when released. Thanks! :)
(In reply to comment #25) > I have committed this fix to funtoo github for keychain and it will be in > version 2.7.1 when released. Thanks! :) > Daniel, Is there an ETA on this future release? I keep checking the homepage in hopes to grab a release instead of patching.
I will try to get a maintenance release out in early May. -Daniel
(In reply to comment #27) > I will try to get a maintenance release out in early May. > > -Daniel > Thanks, A new Gentoo bug was opened for the bump. Bug 319419 which I am working on now. Closing this bug.
