gpg --sign main.c You need a passphrase to unlock the secret key for user: "Graham Murray <graham@gmurray.org.uk>" 1024-bit DSA key, ID 34309C41, created 1999-01-23 gpg: DBG: connection to agent established gpg-agent[23873]: can't connect server: `ERR 67109133 can't exec `/usr/bin/pinen try': No such file or directory' gpg-agent[23873]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[23873]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: "Graham Murray <graham@gmurray.org.uk>" 1024-bit DSA key, ID 34309C41, created 1999-01-23 gpg-agent[23873]: can't connect server: `ERR 67109133 can't exec `/usr/bin/pinen try': No such file or directory' gpg-agent[23873]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[23873]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: Invalid passphrase; please try again ... You need a passphrase to unlock the secret key for user: "Graham Murray <graham@gmurray.org.uk>" 1024-bit DSA key, ID 34309C41, created 1999-01-23 gpg-agent[23873]: can't connect server: `ERR 67109133 can't exec `/usr/bin/pinen try': No such file or directory' gpg-agent[23873]: can't connect to the PIN entry module: IPC connect call failed gpg-agent[23873]: command get_passphrase failed: No pinentry gpg: problem with the agent: No pinentry gpg: no default secret key: Bad passphrase gpg: signing failed: Bad passphrase emerge --info Portage 2.1.2_rc4-r3 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.5-r0, 2.6.19-gentoo-r2 i686) ================================================================= System uname: 2.6.19-gentoo-r2 i686 Intel(R) Pentium(R) 4 CPU 3.20GHz Gentoo Base System version 1.12.8 Last Sync: Sat, 30 Dec 2006 19:50:01 +0000 dev-java/java-config: 1.3.7, 2.0.31 dev-lang/python: 2.4.4 dev-python/pycrypto: 2.0.1-r5 sys-apps/sandbox: 1.2.18.1 sys-devel/autoconf: 2.13, 2.61 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.17 sys-devel/gcc-config: 1.3.14 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.19 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=nocona -mtune=nocona -pipe -ggdb" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config /var/bind" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c" CXXFLAGS="-O2 -march=nocona -mtune=nocona -pipe -ggdb" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks installsources metadata-transfer parallel-fetch sandbox sfperms splitdebug strict" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ http://ftp.du.se/pub/os/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ http://gentoo.mirror.solnet.ch http://gentoo.blueyonder.co.uk" LANG="en_GB.UTF-8" LC_ALL="en_GB.UTF-8" LINGUAS="en_GB" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/portage/local/layman/sunrise /usr/portage/local/layman/musicbrainz" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X a52 aac aalib acl acpi aim alsa apache2 arts audiofile avi bash-completion berkdb bitmap-fonts bluetooth bonobo browserplugin bzip2 bzlib cairo caps cdparanoia cdr cjk cli cracklib crypt cups curl dbus dlloader doc dri dts dvd dvdr dvdread eds emacs emboss encode esd ethereal examples exif expat fam fbcon ffmpeg firefox flac foomaticdb fortran gcj gd gdbm gif glut gmp gnome gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal iconv icq idn ieee1394 imagemagick imlib ipv6 isdnlog jabber jack java javascript jbig jce jpeg jpeg2k junit kde kdehiddenvisibility lcms leim libg++ libgda libnotify libsamplerate lm_sensors logrotate lua mad matroska mbox mikmod milter mime mmap mmx mng mono mp3 mpeg mpi msn ncurses nls nptl nptlonly nsplugin offensive ogg oggvorbis openal opengl oscar oss pam pcntl pcre pdf perl png postgres ppds pppd profile python qt3 qt4 quicktime readline recode reflection ruby sdl seamonkey session sharedmem sndfile snmp sockets sox speex spell spl sse sse2 ssl svg sysvipc tcl tcltk tcpd tetex theora threads tiff tk truetype truetype-fonts type1-fonts udev uicktime unicode usb v4l vim-syntax vorbis win32codecs wmf wxwindows x264 x86 xface xine xml xml2 xorg xv xvid yahoo zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LINGUAS="en_GB" USERLAND="GNU" VIDEO_CARDS="radeon vesa fbdev" Unset: CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
I have just discovered that app-crypt/pinentry needed emerging in order to prompt for the passphrase. I notice that the ebuild has the dependency for this commented out.
I would also like to add that Evolution does not prompt for gpg passphrases with gnupg-2.0.1-r2. Therefore outgoing messages cannot be signed and/or encrypted in Evolution. This occurs even when pinentry is installed.
(In reply to comment #2) > I would also like to add that Evolution does not prompt for gpg passphrases > with gnupg-2.0.1-r2. Therefore outgoing messages cannot be signed and/or > encrypted in Evolution. This occurs even when pinentry is installed. Can you please attach your ~/.gnupg/gpg-agent.conf? It should have an entry of: pinentry-program /usr/bin/pinentry-qt Can you generate a gnupg log out of evolution, and attach it too?
(In reply to comment #3) > Can you please attach your ~/.gnupg/gpg-agent.conf? > It should have an entry of: > pinentry-program /usr/bin/pinentry-qt I don't have a ~/.gnupg/gpg-agent.conf. I never did and it's always worked. When I created one and added that line I get an error that my secret key does not exist. However "gpg --list-secret-keys clearly shows it. > > Can you generate a gnupg log out of evolution, and attach it too? > I don't know how to do that.
(In reply to comment #3) FWIW /usr/bin/pinentry-qt does not exist on my system.
1. Which /usr/bin/pinentry* do you have? Try to use one of them. 2. Can you paste the key list output of gnupg?
I want to make corrections to my previous comments: Evolution works fine with gnupg-1.99* With gnupg-2.0.1-r2 when I try to send a signed message in evolution I get a dialog box stating Could not create message. Because "Failed to unlock secret key: 3 bad passphrases given.", you may need to select different mail options. This is both with and without pinentry installed. pinentry has ncurses, gtk, and qt3 USE flags, of which only ncurses was set. I set the gtk USE flag and re-emerged pinentry. After this I get a pinentry-gtk-2 dialog when I attempt to send a signed email. The email is successfully signed and sent. I then re-emerged pinentry with "-gtk qt" and tried to send an encrypted email in evolution. I got the qt dialog and the email was sent successfully. So to conclude it looks as if Evolution requires pinentry and at least one of the gtk or qt3 flags set on it (most Evo users will probably prefer gtk). I did not have to have a ~/.gnupg/gpg-agent.conf. It worked even when that file was removed (it didn't existed for me to begin with). I also tested signing a file without the DISPLAY variable set and got the ncurses dialog.
Could you emerge pinentry with just ncurses, auth to your agent, (make sure the agent still has your passphrase), then try evolution while your passphrase is cached?
(In reply to comment #8) > Could you emerge pinentry with just ncurses, auth to your agent, (make sure the > agent still has your passphrase), then try evolution while your passphrase is > cached? > I think you're making the assumption that an agent is being used. See the thing is, I've never used an agent. I never specifically start an agent and I don't think that Evolution does either. I'm pretty sure it just calls "gpg --sign". Now, if I start an agent manually in my .xsession (a la the gnupg-agent man page) then, the first time I send a signed message in Evolution then I get prompted for the passphrase. Subsequent signed messages do not prompt me for the password. I normally log into my desktop via gdm (GNOME Display Manager). The default GNOME session for GDM does call ssh-agent but not gnupg-agent. I choose the "Custom" session which calls my ~/.xsession which also only calls ssh-agent. Evolution doesn't appear to call any agent at all. In my previous install if I log into GNOME and run gnupg-agent in a terminal it tells me that no agent is running. So basically I don't think the agent has anything to do with it, just that there was no (X11) pinentry program installed to prompt for the password. So the solution should be: If >=gnupg-2.0 is built: require pinentry If Evolution is built with the "crypt" USE flag: require gnupg as a dependency if >=gnupg-2.0: require pinentry as a dependency require pinentry built with gtk *or* qt3 USE flag The gnupg should probably issue a warning or something to that effect. "If you have Evolution installed you should (re)emerge pinentry with gtk USE flag set.
marduk: please specifically use an agent for that test that I mentioned. graham murray: going back to your original issue, did something in your gnupg or agent config specifically mention pinentry and the agent?
(In reply to comment #10) > marduk: please specifically use an agent for that test that I mentioned. I really don't see the utility of the test. If I log in with GDM and I don't have an X11 version of pinentry then I'm never going to get prompted for a password. But I tried it anyway and that's exactly what happened. The only way I thought it might work is to log in, open an xterm, run "eval `gpg-agent --daemon`" from the command line and then run Evolution from that same xterm. My observations are: * gpg-agent --daemon does not prompt you for a password. Apparently you only get prompted the first time you attempt to use the key. * When I launched Evolution from the same xterm and tried to send a signed email, Evolution locked up and had to be killed. Similiarly, I found a couple of pinentry processes that were using up 99% of my CPU time. When I killed them two more appeared with the same behavior. So my basic conclusion is, if you're using Evolution (remember, that was my original comment), then you need pinentry compiled with support for one of the X11 toolkits, regardless of whether an agent is used or not. I suppose now you're going to ask me to first authenticate using a gpg from the command line and then use Evolution to send signed email, but that's just ridiculous.
marduk: yes, --daemon does not prompt for the password, and pinentry-ncurses would just hang on a terminal like that. Please re-read what the order of operations I asked for in the testcase. I meant that you should start the daemon, and use gnupg to give it a passphrase (on the xterm) then try evolution AFTER the agent had the passphrase. I'm specifically after seeing that the agent is used correctly by evolution when there IS already a passphrase cached.
(In reply to comment #12) Mr Johnson, I think I have a clear enough understanding of what you are asking for, but you apparently are not understanding me. I'm going to try to clarify this one last time. Recall comment #2 where my original statement was that Evolution no longer prompted for PGP passphrase. Recall comment #7 where I report that the solution was to emerge pinentry with one of the X11 USE flags. Recall comment #9 where I report that I have never used an agent before when it worked. Recall comment #11 where I report that it *does* work with the agent so long as pinentry is installed with an X11 USE flag. Not that I care because as per comment #9 I DO NOT USE THE AGENT. Recall comment #11 where I report that, even though I DO NOT USE THE AGENT, I tried using the agent with just ncurses pinentry and it did not work. > I meant that you should start the daemon, and use gnupg to give it a passphrase > (on the xterm) then try evolution AFTER the agent had the passphrase. Recall comment #11 where I say that's just ridiculous. The reason is that I, and when I say "I" i mean the typical user who just wants to open Evolution and send a freaking email, is not going to go in to an xterm, authenticate her passphrase, and then go launch Evolution. And even if said user were to do that, I'm pretty sure *I* would not as I DO NOT USE THE AGENT. I'm not going to bother with your experiment. If you wish you can disregard all my previous comments and close out this bug when you see fit. Just consider it user error, or whatever.
marduk: the purpose of my originally worded test was to establish if why Evolution used to prompt (without any pinentry being present), but no longer does now. I specifically suspect a flaw in Evolutions communication with the agent as if it cannot contact the agent or has an error in doing so, the normal action taken is to have gnupg call pinentry bypassing the agent. mutt has a similar old code behavior to cache the passphrase itself.
Ok, this *really* isn't that difficult so I can only conclude either I'm not communicating effectively or you're just not listening. Look at the original report (comment #1). gpg itself does not prompt for a passphrase without pinentry. Ok, remember that. If you need help it's the bug summary. Don't forget because it comes up again later. Also note that nowhere does the OP mention "agent". Recall that I commented (comment #2) that Evolution also does not prompt for a password. One *might* deduce that since gpg isn't prompting for a password and all-of-the-sudden Evolution is not either, then Evolution might be calling gpg as well. I bet it's even expecting, say 'gpg --sign' to either complete successfully or prompt for a password. Recall gpg knows how to talk to pinentry and can prompt for a password as per comment #1. Evolution probably does not know how to talk to pinentry and probably just calls gpg, but since gpg is calling a ncurses-only pinentry and there is no TERM set then pinentry is probably not able to effectively prompt for a password. Therefore gpg fails Therefore Evolution fails. Now for the agent... this is frustrating... Remember back (comment #9) where I say I'm pretty sure Evolution does not launch an agent and I could see no agent running? Okay, imagine a world without an agent. Say to yourself "There is no agent" about 50 times before proceeding to the next paragraph. Ok, now pinentry is launched with an X11 flag. All-of-the sudden it doesn't need ncurses to prompt for a password. Now let's get back to the Evolution situation. Remember that I theorized that Evolution just calls 'gpg --sign' directly? Now let's play on that theory. Imagine I'm sending a signed email, now Evolution calls 'gpg --sign'. gpg looks for a way to prompt for a password, it calls pinentry. pinentry see's that ther is no TERMinal but there is a DISPLAY, so it calls one of it's X11 front-ends. The user gets prompted for a passphrase. The user enters the correct passphrase. gpg gets the passphrase from pinentry. It successfully signs the "file". It exits successfully. Evolution gets the exit success from gpg, takes the resulting signed message and sends it off. happy(pinentry) ==> happy(gpg) ==> happy(Evolution) ==> happy($USER) See how it all works out, and not once did we have to mention the word "agent". So if you think about Evolution calling gpg directly and not talking to no agent then not only does it make the whole problem simpler but it also explains why it works without the agent. Does this at all jive with you or am I completely blowing smoke out of my ass?
Robin, I started to feel sory for you. I got more info. Hope this helps you out $ pstree -a ... |-evolution-2.8 | |-gpg --verbose --no-secmem-warning --no-greeting --no-tty --status-fd=70 --command-fd=72 --sign --detach --armor ... ... so looks like evolutions *is* calling gpg directly. So what happens if I write a wrapper and trap gpg's stderr? This is with only ncurses set: $ cat gpg.stderr gpg: no running gpg-agent - starting one gpg: DBG: connection to agent established Error opening terminal: unknown. gpg-agent[6916]: command get_passphrase failed: End of file gpg: problem with the agent: IPC write error gpg: Invalid passphrase; please try again ... gpg: problem with the agent: IPC write error gpg: problem with the agent: IPC write error gpg: Invalid passphrase; please try again ... gpg: problem with the agent: IPC write error gpg: problem with the agent: IPC write error gpg: skipped "D4B10828": Bad passphrase gpg: signing failed: Bad passphrase So it looks like with 2.x gpg is calling the agent if there is not one running, the agent calls pinentry, pinentry dies because there's no tty. We all fall down. With gpg-1.x we get: $ cat gpg.stderr gpg: writing to `-' gpg: DSA/SHA1 signature from: "D4B10828 marduk <marduk@python.net>" $ pgrep gpg-agent $ So it looks like you win. gnupg 2.x does call the agent. Hooray! We get an agent! Now we have to pay 10% of everything we earn ;-). So let's update our logic happy(pinentry) ==> happy(gpg-agent) ==> happy(gpg) ==> happy(Evolution) ==> semi-happy($USER) # kinda bummed about the 10% ;-) But effectively we have the same thing: it will only work when pinentry has an X11 front-end. So it looks like we're both right: * With 2.x you get to say "agent"! Wow. * Evolution does call gpg directly and does not interact with an agent * pinentry-(gtk|qt) is still needed for the typical Evolution user. Hopefully this will conclude things and you won't ask me to do silly things with xterms just to send emails with a graphical MUA.
(In reply to comment #10) > graham murray: going back to your original issue, did something in your gnupg > or agent config specifically mention pinentry and the agent? > No, I had migrated from 1.4.6 and do not expicitly call the agent. Looking at the release notes for 2.0.1 it would seem that gpg itself temporarily launches an agent to get the passphrase/key. The first time that I have even heard of pinentry was when I saw the error messages from gpg. I do not have an agent conf and my gnupg config does not mention either agent or pinentry.
Graham Murray: if you just emerge pinentry as you said per comment #1, does your original issue vanish? marduk: thanks, that's a lot closer to what I was looking for. Esp. pstree and stderr output for this line: "Error opening terminal: unknown" It does show that the issue was different from Graham's as well. In his case IPC was failing to connect, but in your case IPC was failing on errors. There is another workaround (sending UPDATESTARTUPTTY to the agent on the Assuan protocol, from an Xterm), but it's so nasty that Evolution will get it's deps changed. I'll open a new bug for the GNOME/Evolution maintainer.
also note that the ebuild is missing ${WANT_AUTOCONF} as per QA request.
I do not like the bound to pinentry solution. It does not work with seahorse at all or any agent. Not sure what launched the passphase pop-up before. But it surely is pinentry now, I see it as window title. I enter my passphrase, and it's never cached. It used to be cached by seahorse-agent which I have running. I believe part of this is due to seahorse not being updated for gpg 2.0. It will compile against it, but doesn't seem to work. Now that pinentry is involved, it doesn't have a chance. And running gpg-agent doesn't seem to cache the passphrase either. So while I am not getting the 3 attempts failed dialog anymore. I am also not getting my passphrase catch and entering it per email is quite annoying. Guess I might need to revert back to gnupg-1.4 so seahorse and etc will start working again. I just want to use gpg with evolution, and have my passphrase cached. This used to work before 2.0 entered tree, and IMHO still would if it was slotted. But going down that path was to much drama. Now I just want my passphrase cached by something and I will be happy. Ideally seahorse because of it's integration with gnome. Thanks
wltjr: assuming seahorse obeys the various input designs for agent stuff, just configure the agent to be seahorse instead of gpg-agent, and using seahorse for input instead of pinentry. The only reason gpgagent and thus pinentry should launch presently is that gnupg is NOT detecting the presence of an agent, and thus fires up one of it's own for the passphrase input.
(In reply to comment #21) > wltjr: assuming seahorse obeys the various input designs for agent stuff, just > configure the agent to be seahorse instead of gpg-agent, and using seahorse for > input instead of pinentry. I am not sure what you mean by configure the agent. I will have to look into that. I do have seahorse-agent running, and in the past that's all it took. I also did gpg-agent --daemon to have that running in the background. Right now I have both seahorse-agent and gpg-agent running. Neither are caching passwords from evo. Again I don't think seahorse has been updated to work with gnupg 2.0. Which would explain why things are not working. When they should be. I never configured anything, thus not sure what I need to configure? Assuming gnupg to be aware of seahorse-agent. But never did that in the past, it was detected at runtime or something seamless :)
Ok after looking around, it seems when seahorse-agent starts it modifies my gpg.conf file like. gpg-agent-info /wlt/.gnome2/seahorse-I6p4RQ/S.gpg-agent:5094:1 Pretty much confirming at this point that seahorse does not work with gnupg 2.0. I changed nothing, I simply emerged gnupg-1.4.6, and when I sent an email out of evo without logging out, restarting agent or anything beyond emerging 1.4.6. I got a passphrase prompt window, with passphrase as the title, not pinentry. I entered my passphrase and it is catched as it was before. Got my lock going in my notification area. Where I can clear the cached passphrases or view the ones that are catched. I pretty much have known seahorse does not work with gnupg 2.0 for quite some time. Despite efforts to patch it to compile against it. But since functionality has changed a bit in gnupg 2.0. Seahorse has not been updated to work with that new functionality. In fact I am not sure it ever will since gnupg 1.x will still be developed and offered. And there are valid reasons to depend on only a 1.x version. Even seahorse 9.x does not seem to support gnupg 2.0 yet. I had hoped for gnupg to be slotted, but that became to much drama. So for a month or so now, I am back to where I was at. Having to p.mask > 1.4.6. Which leads to other issues when I need to update my system. So looks like I will have to drop that p.mask. Let gnupg updrade to 2.x, and then once I am done updating, emerge =gnupg-1.4.6, and put back the p.mask. Haven't been to happy about this breakage for some time. But not much I can do :( Hope that helps to understand the situation a bit.
(In reply to comment #23) > Hope that helps to understand the situation a bit. Sure! Now that I know where to look... Found a bug in gnupg... The gpg-agent-info was completely ignored! Fixed in next revision. Now seahorse crashes, I will fix this too. William, I think that part of our mission is to help upstream to solve issues...
OK. Found seahorse issue. It will take me some time...
Great no worries. Let me know if I can help by testing or etc. I can kludge things to work like I have in the mean time. So no rush, but sooner the better :) Thanks
I've put seahorse patch at bug#164523.
OK... Upstream does not accept the gpg-agent-info option fixup... gnupg-2.0.2 will not accept this option. I really don't know why they wish to break an existing behavior... So you must run seahorse at xinit environment and use: eval `seahorse-agent --variables` It will set GPG_AGENT_INFO variable correctly for application to use.
They broke existing behavior because gnupg 1 and 2 are different and work differently. That's also why they said at least publicly they would continue to develop gnupg 1. Why I had originally called for them to be slotted. But so be it. I am trying to leave things as is with gnupg 1.x since it works as expected and always has. However it makes package management quite difficult, but I can deal and likely will have to. Oh well such it life. I currently call seahorse-agent when I start gnome in my session. I will see if adding the --variables will allow it to work with gnupg 2.0 . But tired of trying to find alternative ways to make something that used to work, and works fine one way, work another way. No time for that, sorry :)
William: Please try the patch I submitted at bug#164523, I am still waiting for your response. The breakage of gpg-agent-options should not have happened, but upstream insist to remove this option. It is not like seahorse was not aware of the GPG_AGENT_INFO environment variable, this is why they already implemented the --variables option. So I thing that our efforts are still in the right direction.
(In reply to comment #30) > William: Please try the patch I submitted at bug#164523, I am still waiting for > your response. I will I am sorry for the delay with that. I have not had the time. Been out of the office a bit and when I am in need everything to work. To fully test I will have to log out and back in. Which stops my world on this machine. Much less having to re-cache my gnupg passphrases which due to length I always screw up and have to enter i more than once. And caching my ssh passphrase etc. That all is the time killer, and will happen during trial and error several times. Much less any of the package merging or testing other options. Lost a good deal of time already. But I will try patch ASAP. I hope to tomorrow or Sunday at latest my sys admin/upgrade day. I will report back how it all goes, hopefully that it works. :)
*** This bug has been marked as a duplicate of bug 164523 ***
