bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Teodor Zlatanov]

1. Install GnuPG 2.x, don't run gpg-agent
2. Open file.gpg, X or curses pinentry dialog pops up

The suggested workaround is to run gpg-agent.

Problems:

- on a headless server this can lock up Emacs

- if the GPG agent is dead, locked up, or not running, there's no remedy

- the X pinentry dialog is very non-specific ("Enter passphrase") so
  there's no way to know what passphrase is being requested and why if
  you don't have the specific instance in focus.

- there's no way to avoid the prompt in favor of an Emacs minibuffer query



In GNU Emacs 24.3.50.2 (x86_64-unknown-linux-gnu, GTK+ Version 3.4.4)
 of 2013-09-20 on flea.lifelogs.com
Bzr revision: 114415 rgm@gnu.org-20130921005207-1eq49miu7feptu8i
Windowing system distributor `The X.Org Foundation', version 11.0.11304000
System Description:	Gentoo Base System release 2.2

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Daiki Ueno]

tags 15553 notabug
thanks

Teodor Zlatanov <tzz@lifelogs.com> writes:

> 1. Install GnuPG 2.x, don't run gpg-agent
> 2. Open file.gpg, X or curses pinentry dialog pops up
>
> The suggested workaround is to run gpg-agent.

So you can workaround, what's your problem?

> Problems:
>
> - on a headless server this can lock up Emacs

Not a problem if you use the workaround.

> - if the GPG agent is dead, locked up, or not running, there's no remedy

Ditto.

> - the X pinentry dialog is very non-specific ("Enter passphrase") so
>   there's no way to know what passphrase is being requested and why if
>   you don't have the specific instance in focus.

Unreleated to this bug, please open a new one.

> - there's no way to avoid the prompt in favor of an Emacs minibuffer query

As I said a number of times, that degrades security.  If the insecurity
is okay for you, what's the reason you want to use GnuPG 2.x rather than
GnuPG 1.x?

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Ted Zlatanov]

On Tue, 08 Oct 2013 08:54:17 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Teodor Zlatanov <tzz@lifelogs.com> writes:

>> 1. Install GnuPG 2.x, don't run gpg-agent
>> 2. Open file.gpg, X or curses pinentry dialog pops up
>> 
>> The suggested workaround is to run gpg-agent.

DU> So you can workaround, what's your problem?

See below.

>> Problems:
>> 
>> - on a headless server this can lock up Emacs

DU> Not a problem if you use the workaround.

>> - if the GPG agent is dead, locked up, or not running, there's no remedy

DU> Ditto.

Look.  gpg-agent is an external daemon.  Kill it manually or it dies
accidentally or it blocks for whatever reason.  Now the user has no
access to their secret data and Emacs could even completely lock up.

You're assuming access to a resource that you can't verify (gpg-agent).
Or rather, GnuPG is depending on it.

>> - there's no way to avoid the prompt in favor of an Emacs minibuffer query

DU> As I said a number of times, that degrades security.  If the insecurity
DU> is okay for you, what's the reason you want to use GnuPG 2.x rather than
DU> GnuPG 1.x?

I'd rather not use either but have no choice right now.  I would like to
avoid the GnuPG dependency altogether as I've explained.  Anyhow, I was
hoping that GnuPG 2.x can provide a special option (as we've discussed
that you could propose) to make this possible.  If that's not your
interest, then let's just call this one done as a "user misunderstanding
of basic security" or whatever you like.

Thanks for your time
Ted

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> Look.  gpg-agent is an external daemon.  Kill it manually or it dies
> accidentally or it blocks for whatever reason.

It's as easy to restart as kill it manually.  Even gpg2 automatically
respawns it if it is not running.  If it dies accidentally or blocks,
you should report it to GnuPG.

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Stefan Monnier]

>> - on a headless server this can lock up Emacs

That's not good.  We should try to make sure that detect the
problematic situation, or make it easy for the user to get out of it
(with something like a C-g).

>> - if the GPG agent is dead, locked up, or not running, there's no remedy
> Ditto.

It can be very annoying for the user, and tricky to trackdown, so it's
clearly a real problem.  Of course, I have no idea how easy it would be
to fix it, but that doesn't make it a non-problem.  It incidentally does
sound like it matches the symptom of a problem I've had a few times
(tho I never bothered to track it down enough to be able to confirm
that it was indeed this problem).

>> - there's no way to avoid the prompt in favor of an Emacs minibuffer query
> As I said a number of times, that degrades security.  If the insecurity
> is okay for you, what's the reason you want to use GnuPG 2.x rather than
> GnuPG 1.x?

Maybe the user doesn't really want to use gpg2 (maybe it's installed for
some other user, maybe gpg1 is not installed for some reason, or maybe
the user didn't realize that gpg1 is not obsoleted by gpgp2), yet the
user may not care about the degraded security.


        Stefan

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Daiki Ueno]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> - on a headless server this can lock up Emacs
>
> That's not good.  We should try to make sure that detect the
> problematic situation, or make it easy for the user to get out of it
> (with something like a C-g).

I doubt such a hard lockup is possible, as epg.el uses async process.

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Stefan Monnier]

>>>> - on a headless server this can lock up Emacs
>> That's not good.  We should try to make sure that detect the
>> problematic situation, or make it easy for the user to get out of it
>> (with something like a C-g).
> I doubt such a hard lockup is possible, as epg.el uses async process.

But it calls accept-process-output, so it can still get stuck.  And even
if inhibit-quit is nil, maybe there's no frame open anywhere so the user
can't hit C-g.  So the only recourse would be connecting to it via
another emacsclient, which might fail to work if Emacs is stuck in an
accept-process-output waiting for a specific process.


        Stefan

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Daiki Ueno]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>>> - on a headless server this can lock up Emacs
>>> That's not good.  We should try to make sure that detect the
>>> problematic situation, or make it easy for the user to get out of it
>>> (with something like a C-g).
>> I doubt such a hard lockup is possible, as epg.el uses async process.
>
> But it calls accept-process-output, so it can still get stuck.

Yes, but it's not a hard lockup.  I can get out from the loop with C-g.

And actually Emacs 24 has the code to allow pinentry to fallback into
the curses mode in that case (though the interaction is not very well).

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Stefan Monnier]

>> But it calls accept-process-output, so it can still get stuck.
> Yes, but it's not a hard lockup.  I can get out from the loop with C-g.

But if you have no terminal open (yet) on that emacs-server, you can't
hit C-g.

> And actually Emacs 24 has the code to allow pinentry to fallback into
> the curses mode in that case (though the interaction is not very well).

And same as above: there might not be any tty for curses to talk to.


        Stefan

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Daiki Ueno]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>> But it calls accept-process-output, so it can still get stuck.
>> Yes, but it's not a hard lockup.  I can get out from the loop with C-g.
>
> But if you have no terminal open (yet) on that emacs-server, you can't
> hit C-g.

Well, is that a realistic use case?  What do you suppose precisely?

I thought that you meant like:

  $ emacs -nw file.gpg

or even

  $ emacs -batch -l file.el.gpg

on a remote terminal.  Either works fine here with pinentry-curses.

bug#15553: 24.3.50; epg.el and GnuPG 2.x cause unavoidable pinentry prompts for symmetrically encrypted files

[Stefan Monnier]

>>>> But it calls accept-process-output, so it can still get stuck.
>>> Yes, but it's not a hard lockup.  I can get out from the loop with C-g.
>> But if you have no terminal open (yet) on that emacs-server, you can't
>> hit C-g.
> Well, is that a realistic use case?  What do you suppose precisely?

> I thought that you meant like:
>   $ emacs -nw file.gpg
> or even
>   $ emacs -batch -l file.el.gpg

Sorry I didn't use the right terminology.  I meant an "emacs --daemon"
I.e. run an emacs process as a server and then connect to it via
emacsclient.  This server can sit in the background with no tty nor GUI
frame open anywhere.  If you then "emacsclient -eval <something>" and
this <something> involves opening a .gpg file you might get stuck with
an emacs server.  In any case, this is hypothetical.  I haven't even
tried it, and who knows maybe it does behave properly in the end
(e.g. gpg2 errors out because it can't find any X11 display nor any tty
to use to prompt the user).

So let's not worry about it too much until there's a concrete
problematic case.


        Stefan