Bug 574406 - can't open gpg-encrypted file in remote emacs in F13 alpha
Summary: can't open gpg-encrypted file in remote emacs in F13 alpha
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Fedora
Classification: Fedora
Component: emacs
Version: 13
Hardware: All
OS: Linux
low
high
Target Milestone: ---
Assignee: Karel Klíč
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 617056
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-03-17 13:45 UTC by Jonathan Kamens
Modified: 2013-03-03 23:00 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-18 17:27:54 UTC
Type: ---


Attachments (Terms of Use)

Description Jonathan Kamens 2010-03-17 13:45:00 UTC
When I open a gpg-encrypted file in emacs in F12, I get prompted for the passphrase in my minibuffer and the file is decrypted automatically.

There's apparently some new GPG key agent or something in F13 alpha that is interfering with this, in particular when I am logged in remotely.

I'm logged in on the console of my home machine.  When I log in remotely from work through ssh, start emacs, and try to open a GPG-encrypted file, I see this in my minibuffer:

-111:**--F1  *shell*        All L1     (Shell:run)------------------------------
/home/jik/closed/sit: 0% (0/7285)

(The path you see is the first part of the file path.)

Then emacs hangs.

This is, in my opinion, a serious regression in functionality.

Comment 1 Karel Klíč 2010-04-14 13:39:07 UTC
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.

Comment 2 Karel Klíč 2010-04-14 13:48:58 UTC
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.

Comment 3 Jonathan Kamens 2010-04-14 20:59:30 UTC
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.

Comment 4 Karel Klíč 2010-04-14 21:36:13 UTC
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.

Comment 5 Jonathan Kamens 2010-04-14 21:39:32 UTC
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?

Comment 6 Jonathan Kamens 2010-04-14 21:41:09 UTC
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.

Comment 7 Jonathan Kamens 2010-04-14 21:42:50 UTC
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.

Comment 8 Jonathan Kamens 2010-04-14 21:43:24 UTC
It's hard to understand why the GNU package gnupg2 felt it was reasonable to break functionality in the GNU package emacs.

Comment 9 Henrique Martins 2010-05-27 13:09:04 UTC
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.

Comment 10 Henrique Martins 2010-05-27 13:15:17 UTC
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.

Comment 11 Henrique Martins 2010-05-27 13:25:22 UTC
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.

Comment 12 Henrique Martins 2010-05-28 14:51:40 UTC
(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.

Comment 13 Brian Lane 2010-06-01 02:12:18 UTC
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.

Comment 14 Henrique Martins 2010-06-01 04:08:45 UTC
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.

Comment 15 David Shaw 2010-07-12 18:02:03 UTC
(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?

Comment 16 Karel Klíč 2010-07-13 08:58:37 UTC
I sent an email about this issue to fedora-devel mailing list.

Comment 17 Brian Lane 2010-08-20 16:00:18 UTC
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

Comment 18 Henrique Martins 2010-08-20 17:25:52 UTC
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?)

Comment 19 Karel Klíč 2010-09-06 12:07:02 UTC
Does the gnupg-1.4 revival fixed this bug?

Comment 20 Jonathan Kamens 2010-09-15 17:45:44 UTC
I don't see gnupg in updates-testing for F14.

Comment 22 Karel Klíč 2011-04-18 17:27:54 UTC
I think this issue has been resolved for some time now.

Comment 23 Mark Alford 2012-10-09 22:28:37 UTC
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

Comment 24 Henrique Martins 2012-10-09 22:50:15 UTC
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.

Comment 25 Mark Alford 2012-10-10 14:15:41 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.