Bug 574406

That is probably caused by gnupg package removal from Fedora (gnupg2 is the only possibility now).

Gnupg2 runs pinentry-{gtk-2,curses} to get the password, and Emacs does not work with pinentry. Pinentry usage also cannot be disabled from the command line.

http://www.gnu.org/software/emacs/manual/html_node/message/Using-PGP_002fMIME.html

From the Emacs Manual:
Under the X Window System, you will see a new passphrase input dialog appear. The dialog is provided by PIN Entry (the pinentry command), and as of version 0.7.2, pinentry cannot cooperate with Emacs on a single tty. So, if you are using a text console, you may need to put a passphrase into gpg-agent's cache beforehand.

I don't see any evidence that gdm or gnome is starting up gpg-agent.  I also can't find a good way to integrate it into the gnome startup sequence.  And I shouldn't have to figure this out.  It worked out of the box in F12, so it should work out of the box in F13, or it's a regression.

Jonathan, I agree with you this is a regression. I just do not know how to fix it. The best solution now seems to get back the older gnupg 1.x.

Regarding the gpg-agent, gpg manual page in F-13 says: 
   --no-use-agent
          This is dummy option. gpg2 always requires the agent.
Whereas in F-12 this option works and disables the agent usage.

So emacs runs gpg and it runs gpg-agent, which tries to run pinentry-curses and Emacs cannot handle that.

Incorporate GPG agent into the polkit daemon like SSH agent is incorporated into it?

Start GPG agent from the default Xsession shell script before gnome-session is called?

Add a default startup application to GNOME that starts gpg-agent with --use-default-socket?

To be clear, all of these will start an agent, but none of them will automatically preset the passphrase so that it can be used in a remote session.  To do that, you would have to decrypt at least one file using the passphrase on the console before logging in remotely.

Also, I should mention that _sometimes_ when I try to read a .gpg file in emacs in a remote session, it successfully pops up the X pinentry window, and sometimes it doesn't.  I haven't been able to figure out what distinguishes the success case from the failure case.

Another option would be to configure emacs to set the necessary environment variables to tell gpg to use a pinentry program that prompts for the passphrase on stdin, i.e., to fix whatever was broken in pinentry 0.7.2 so that emacs can once again prompt for the passphrase and feed it to gnupg like it used to.

It's hard to understand why the GNU package gnupg2 felt it was reasonable to break functionality in the GNU package emacs.

Can someone explain to me how to use this from a console, i.e. on a system that doesn't run X?

Can't find a repo with the standalone gpg/gnupg, even though the man page for gpg2 claims that it will be maintained and can be installed along with it.  And on my system gpg is a link to gpg2, so something will need to be changed there too.

Answering my own question :-)  I had DISPLAY set and gpg decided to use, need to unset DISPLAY to run it from the console and it uses some silly visual interface.
Try that one with TERM=dumb for a completely new experience.  Ah, progress...

And I'm sure I'm going to need someone to fix the remote emacs/xemacs thing at some point.

Well, it doesn't even work with my xemacs on the main display.

Running it from the command line/xterm spits out these two error lines
 can't connect to `/home/<user>/.gnupg/S.gpg-agent': No such file or directory
 (12987) KIconTheme::KIconTheme: Icon theme  "crystalsvg"  not found.

So now wen I decrypt a file, I may need some agent, KDE, and a theme, for it to not generate silly error messages?

Please build standalone gpg for f13.  This is a bit useless.

(Looks like my followup didn't make it, or I forgot to press submit.)

Downloaded gnupg 1.4.10 from gunpg.org.  Recompiled it.  Installed it.  Works fine alongside gnupg2 2.0.14 that comes with F13.

The GnuPG website, the man page, etc, all claim that gnupg will be maintained along with gnupg2, for servers and embedded systems.  Guess they should add X/Emacs users to that list.

Any reason this can't be repackaged and put back in F13?  It's certainly is a must for me.

Also, in a response/comment to comment #2 above,  I don't have A password to put in gpg-agent's cache.  I have different password for different encrypted files and thus will need to enter them as needed.

I'll add my usage to this bug instead of making a new one -- I typically ssh to remote systems and use vim to edit gpg files (using :%!gpg), with this new system I don't get a passphrase prompt at all.

I think a serious mistake was made in a) not including gnupg 1.x in F13 and b) symlinking /usr/bin/gpg to gpg2. Since the functionality is NOT identical, it would be better to remove the symlink and allow gpg and gpg2 to be installed at the same time.

It's a mistake that can only be made by those that don't use gpg.  And gpg 1.4x compiles and installs on f13 without a hitch, so I'm not sure what the problem is to begin with.

(In reply to comment #13)
> I'll add my usage to this bug instead of making a new one -- I typically ssh to
> remote systems and use vim to edit gpg files (using :%!gpg), with this new
> system I don't get a passphrase prompt at all.
> 
> I think a serious mistake was made in a) not including gnupg 1.x in F13 and b)
> symlinking /usr/bin/gpg to gpg2. Since the functionality is NOT identical, it
> would be better to remove the symlink and allow gpg and gpg2 to be installed at
> the same time.    

Very strong agreement.

I can't say whether the Emacs issue at hand should be resolved with fixing things to work properly with Gnupg2 or not, but certainly the gnupg2 RPM should not preclude creating and installing a gnupg1 RPM.  They are not the same package, and are both maintained for different (albeit somewhat overlapping) purposes.  This worked properly in F11 (using "gpg" and "gpg2" as binary names).

What should be the next step in resolving this?  A bug against gnupg2?  Something else?

I sent an email about this issue to fedora-devel mailing list.

gnupg 1.4.10 has been revived for F13 and beyond. You can help test by installing it from the updates-testing repository like this:

sudo yum --enablerepo=updates-testing install gnupg gnupg2

The current versions are:
gnupg2-2.0.14-6.fc13.x86_64
gnupg-1.4.10-2.fc13.x86_64

Make sure you have gnupg2-2.0.14-6 or later, that version removes restrictions that keep gnupg-1.4.10-2 from installing.

Please report any problems by opening a bug against gnupg and leaving feedback/karma on this update:

https://admin.fedoraproject.org/updates/gnupg2-2.0.14-6.fc13,gnupg-1.4.10-2.fc13

Installed and seems to work from xemacs and CLInvocation on my x86 and x86_64 systems.  Will keep an eye on it.  (How does one leave karma on bohdi anyway?)

Does the gnupg-1.4 revival fixed this bug?

I don't see gnupg in updates-testing for F14.

I can see it both in F13 and F14.

http://mirrors.kernel.org/fedora/updates/13/i386/gnupg-1.4.10-2.fc13.i686.rpm

http://mirrors.kernel.org/fedora/development/14/i386/os/Packages/gnupg-1.4.10-2.fc14.i686.rpm

I think this issue has been resolved for some time now.

The bug has recurred in Fedora 17. Installing gpg along with gpg2 does not fix it. It can be fixed by telling emacs not to use gpg-agent to get the passphrase, by adding this line to the .emacs configuration file:
(setenv "GPG_AGENT_INFO" nil)

See http://www.gnu.org/software/emacs/manual/html_mono/epa.html

I haven't seen this in F17 and xemacs, and I've upgraded to F17 fairly soon after release.  But I don't run a desktop environment like gnome or kde and don't have any GPG environment variables set.

Sorry, my comment https://bugzilla.redhat.com/show_bug.cgi?id=574406#c23 was meant for a different bug, https://bugzilla.redhat.com/show_bug.cgi?id=601986. I will post it there now.