bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

It used to be possible to do

GPG_AGENT_INFO=none gpg --decrypt foo.gpg
GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg
etc.

but with GPG 2.x that seems to be disabled and the pinentry prompt pops
up no matter what.  Without waiting for changes on the GPG side, the
only option seems to be to downgrade to GPG 1.x, which is not a great
solution.  I haven't found a configuration option to disable the popup,
and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't
work:

% unset GPG_AGENT_INFO
% gpg --batch --decrypt authinfo.gpg
gpg: CAST5 encrypted data
gpg-agent[28496]: can't connect to the PIN entry module: IPC connect call failed
gpg-agent[28496]: command get_passphrase failed: No pinentry
gpg: problem with the agent: No pinentry
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key

The effect to Emacs users is that the pinentry passphrase dialog comes
up over and over, at least in X.  It makes working with .gpg files (in
VCS in particular) practically unusable and I haven't found a way to
disable the pinentry prompt.

I want to request either some workaroung or changes in epg.el or the
ability to use another encryption backend besides GPG,
e.g. http://ccrypt.sourceforge.net/

I am not opening a bug because it's not really a bug on our side IIUC.
Any advice is welcome... I hope I missed something in the GPG2 docs!

Thanks
Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Thierry Volpiatto]

Ted Zlatanov <tzz@lifelogs.com> writes:

> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
> up no matter what.  Without waiting for changes on the GPG side, the
> only option seems to be to downgrade to GPG 1.x, which is not a great
> solution.  I haven't found a configuration option to disable the popup,
> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't
> work:

Did you try to uninstall gnupg-agent packet?
(It is a separate packet on debian based distro e.g ubuntu)

BTW I have no problems with pinentry prompt.

-- 
Thierry
Get my Gnupg key:
gpg --keyserver pgp.mit.edu --recv-keys 59F29997 

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It used to be possible to do
>
> GPG_AGENT_INFO=none gpg --decrypt foo.gpg
> GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg
> etc.
>
> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
> up no matter what.  Without waiting for changes on the GPG side, the
> only option seems to be to downgrade to GPG 1.x, which is not a great
> solution.  I haven't found a configuration option to disable the popup,
> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't
> work:

Nowadays, GnuPG 2.1 or later has --pinentry-mode option, which provides
a way to bypass the graphical pinentry prompt, like:

$ gpg --batch --decrypt --pinetry-mode=loopback authinfo.gpg

which just behaves like gpg1.  I added the support to epg.el (see
epg-pinentry-mode) some time ago, but not yet added any user option in
epa.el.

Patches (and testing) are welcome.

Regards,
-- 
Daiki Ueno

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Sun, 29 Sep 2013 17:07:02 +0200 Thierry Volpiatto <thierry.volpiatto@gmail.com> wrote: 

TV> Ted Zlatanov <tzz@lifelogs.com> writes:
>> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
>> up no matter what.  Without waiting for changes on the GPG side, the
>> only option seems to be to downgrade to GPG 1.x, which is not a great
>> solution.  I haven't found a configuration option to disable the popup,
>> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't
>> work:

TV> Did you try to uninstall gnupg-agent packet?
TV> (It is a separate packet on debian based distro e.g ubuntu)

TV> BTW I have no problems with pinentry prompt.

If you look at my example, I disable the GPG agent.  It's not the
problem.  Disabling pinentry doesn't work either.

Make sure you're using GnuPG 2.x (I tested with 2.0.20).

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Sun, 29 Sep 2013 11:24:56 -0400 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>> It used to be possible to do
>> 
>> GPG_AGENT_INFO=none gpg --decrypt foo.gpg
>> GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg
>> etc.
>> 
>> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
>> up no matter what.  Without waiting for changes on the GPG side, the
>> only option seems to be to downgrade to GPG 1.x, which is not a great
>> solution.  I haven't found a configuration option to disable the popup,
>> and even removing /usr/bin/pinentry and disabling the gpg-agent doesn't
>> work:

DU> Nowadays, GnuPG 2.1 or later has --pinentry-mode option, which provides
DU> a way to bypass the graphical pinentry prompt, like:

DU> $ gpg --batch --decrypt --pinetry-mode=loopback authinfo.gpg

DU> which just behaves like gpg1.  I added the support to epg.el (see
DU> epg-pinentry-mode) some time ago, but not yet added any user option in
DU> epa.el.

DU> Patches (and testing) are welcome.

I'd love to test and patch, but the latest GnuPG release is 2.0.21 and I
can't find mentions of 2.1 on their website.  2.0.20 doesn't have the
--pinentry-mode option by default (tested in Gentoo).  I assume this is
the relevant commit that introduces it:

http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=commit;h=21feecd48f990b2569cb4b385dea3e57b9501525

It seems that GnuPG has to be explicitly compiled with
--allow-loopback-pinentry which IMO is a really painful requirement to
pass onto Emacs users.  I am surprised by this, but perhaps I've
misunderstood something?

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
> up no matter what.

What happens if you redirect stdin from /dev/null?


        Stefan

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Mon, 30 Sep 2013 14:53:38 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
>> up no matter what.

SM> What happens if you redirect stdin from /dev/null?

Same outcome.  Removing /usr/bin/pinentry is the only way to stop the
popup; if I put /usr/bin/pinentry back I get the curses or X popup no
matter what:

% echo x > /tmp/t
% mv /usr/bin/pinentry /usr/bin/pinentry.bak
% gpg --passphrase-fd=0 --decrypt authinfo.gpg  < /tmp/t
gpg: CAST5 encrypted data
gpg-agent[28972]: can't connect to the PIN entry module: IPC connect call failed
gpg-agent[28972]: command get_passphrase failed: No pinentry
gpg: problem with the agent: No pinentry
gpg: encrypted with 1 passphrase
gpg: decryption failed: No secret key

% mv /usr/bin/pinentry.bak /usr/bin/pinentry
% gpg --passphrase-fd=0 --decrypt authinfo.gpg  < /tmp/t
(pinentry query UGH)

Oh, I finally found a workaround!  No idea if it would work in the GnuPG
2.1 release Ueno-san mentioned because I can't find a 2.1, but this
worked for me with 2.0.20:

gpg --passphrase-fd=0 --batch --decrypt authinfo.gpg  < /tmp/t

This mode is not used in epg.el right now, so the popup keeps happening.

I can try to patch this myself but it seems, with the potential GnuPG
2.1 and the other pinentry developments mentioned by Ueno-san, that I
should leave this to him because I don't know the full story.  The
obvious fix here could break something else with the next release.

Should I open a bug, then, with the suggested workaround?  Or wait?  The
multiple popups are really annoying.

Thanks!
Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

> Should I open a bug, then, with the suggested workaround?  Or wait?  The
> multiple popups are really annoying.

I must say I don't really understand what is the problem you're
describing (I mean: in what way does it affect Emacs), so I'll let
you judge.

AFAIK it's perfectly OK to popup a password prompt when needed and
I don't know under what circumstance this would be a problem.


        Stefan

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Mon, 30 Sep 2013 18:49:11 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> Should I open a bug, then, with the suggested workaround?  Or wait?  The
>> multiple popups are really annoying.

SM> I must say I don't really understand what is the problem you're
SM> describing (I mean: in what way does it affect Emacs), so I'll let
SM> you judge.

SM> AFAIK it's perfectly OK to popup a password prompt when needed and
SM> I don't know under what circumstance this would be a problem.

Using symmetric (passphrase) encryption:

open authinfo.gpg in a buffer -> prompt
edit
save -> prompt
VCS commit -> 2 or 3 prompts

4-5 prompts, I lost counts.  This is the default behavior with GnuPG
2.0.20 and can't be turned off in a config file.  To fix it, epg.el must
be changed to use `--passphrase-fd=0 --batch' as I found today.

The old behavior was, when GPG_AGENT_INFO was disabled, to ask for the
password in an Emacs prompt.  That fix doesn't work now.

Daiki Ueno, however, told me the behavior was different in 2.1 with
--pinentry-mode=loopback but I can't find such a release even though I
found the commit.  So I have no idea what the right fix is, at this
point.

I hope that summary helps.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

SM> AFAIK it's perfectly OK to popup a password prompt when needed and
SM> I don't know under what circumstance this would be a problem.

> Using symmetric (passphrase) encryption:

> open authinfo.gpg in a buffer -> prompt
> edit
> save -> prompt
> VCS commit -> 2 or 3 prompts

I don't see how that relates to your previous question, which was about
preventing the prompt from appearing at all, rather than about making
sure that previous passwords are recorded and reused in subsequent uses.


        Stefan

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Mon, 30 Sep 2013 20:40:08 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

SM> AFAIK it's perfectly OK to popup a password prompt when needed and
SM> I don't know under what circumstance this would be a problem.

>> Using symmetric (passphrase) encryption:

>> open authinfo.gpg in a buffer -> prompt
>> edit
>> save -> prompt
>> VCS commit -> 2 or 3 prompts

SM> I don't see how that relates to your previous question, which was about
SM> preventing the prompt from appearing at all, rather than about making
SM> sure that previous passwords are recorded and reused in subsequent uses.

I see.  Sorry for confusing you.  Here's what I wrote originally:

TZ> It used to be possible to do
TZ> GPG_AGENT_INFO=none gpg --decrypt foo.gpg
TZ> GPG_AGENT_INFO=none gpg --batch --decrypt foo.gpg
TZ> etc.

TZ> but with GPG 2.x that seems to be disabled and the pinentry prompt pops
TZ> up no matter what
....
TZ> The effect to Emacs users is that the pinentry passphrase dialog comes
TZ> up over and over, at least in X.  It makes working with .gpg files (in
TZ> VCS in particular) practically unusable and I haven't found a way to
TZ> disable the pinentry prompt.

So very specifically, the external pinentry prompt is preventing the
`epa-file-cache-passphrase-for-symmetric-encryption' defcustom from
operating properly.  Ideally I don't want the initial graphical popup
either--it's very annoying--but I can live with one popup.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stephen J. Turnbull]

Ted Zlatanov writes:

 > be changed to use `--passphrase-fd=0 --batch' as I found today.

 > --pinentry-mode=loopback

I bet the implementation of the latter is the former.

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> It seems that GnuPG has to be explicitly compiled with
> --allow-loopback-pinentry which IMO is a really painful requirement to
> pass onto Emacs users.  I am surprised by this, but perhaps I've
> misunderstood something?

Why don't you ask Werner directly about the ideas behind this, instead
of complaining here and seeking for a workaround?

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>> It seems that GnuPG has to be explicitly compiled with
>> --allow-loopback-pinentry which IMO is a really painful requirement to
>> pass onto Emacs users.  I am surprised by this, but perhaps I've
>> misunderstood something?

DU> Why don't you ask Werner directly about the ideas behind this, instead
DU> of complaining here and seeking for a workaround?

Because the bug or misbehavior is specifically in epg.el and I don't
know the best way to fix it.

If you're suggesting I should start fixing epg.el bugs and tracking
GnuPG development, that's a different request I won't be able to fulfill.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: 
>
> DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> It seems that GnuPG has to be explicitly compiled with
>>> --allow-loopback-pinentry which IMO is a really painful requirement to
>>> pass onto Emacs users.  I am surprised by this, but perhaps I've
>>> misunderstood something?
>
> DU> Why don't you ask Werner directly about the ideas behind this, instead
> DU> of complaining here and seeking for a workaround?
>
> Because the bug or misbehavior is specifically in epg.el and I don't
> know the best way to fix it.

Well, I didn't mean to attack you.

I guess the configure option is disabled by default because it
apparently has a security risk and there are not so many users of that
feature.  If you could provide a use case, that might help convince him
to make --allow-loopback-pinentry enabled by default (and release 2.2
and/or backport it to 2.0).

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Andrey Kotlarski]

[  2 октомври 2013, 15:48 +0300, сряда ] Daiki Ueno:

>...
> I guess the configure option is disabled by default because it
> apparently has a security risk and there are not so many users of that
> feature.  If you could provide a use case, that might help convince him
> to make --allow-loopback-pinentry enabled by default (and release 2.2
> and/or backport it to 2.0).

Another vote against this pinentry prompt - makes epg.el unusable on
headless servers, emacs happily freezes on opening .gpg file.

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Wed, 02 Oct 2013 21:48:19 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>> On Wed, 02 Oct 2013 16:23:27 +0900 Daiki Ueno <ueno@gnu.org> wrote: 
>> 
DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>>>> It seems that GnuPG has to be explicitly compiled with
>>>> --allow-loopback-pinentry which IMO is a really painful requirement to
>>>> pass onto Emacs users.  I am surprised by this, but perhaps I've
>>>> misunderstood something?
>> 
DU> Why don't you ask Werner directly about the ideas behind this, instead
DU> of complaining here and seeking for a workaround?
>> 
>> Because the bug or misbehavior is specifically in epg.el and I don't
>> know the best way to fix it.

DU> Well, I didn't mean to attack you.

OK, I didn't take it that way :)

DU> I guess the configure option is disabled by default because it
DU> apparently has a security risk and there are not so many users of that
DU> feature.  If you could provide a use case, that might help convince him
DU> to make --allow-loopback-pinentry enabled by default (and release 2.2
DU> and/or backport it to 2.0).

See my earlier e-mails.  But my bigger concern is that for many users, a
new GnuPG release is years in the future, so even if you justify this
change, it won't help anyone quickly.  IMHO epg.el should work around
this "feature" now with the --batch --passphrase-fd options that I
mentioned, especially if they can work on all GnuPG versions (I haven't
tested that).

My question now, since we understand the problem well, is if you agree
with this plan, and if so, do you need patches from me or other
contributors, or will you address it yourself?  There's no urgency
implied here; I am simply trying to fix this for our users by the next
Emacs release.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> See my earlier e-mails.  But my bigger concern is that for many users, a
> new GnuPG release is years in the future, so even if you justify this
> change, it won't help anyone quickly.  IMHO epg.el should work around
> this "feature" now with the --batch --passphrase-fd options that I
> mentioned, especially if they can work on all GnuPG versions (I haven't
> tested that).

Well, that's a design decision not to use --batch here (and probably in
GPGME).  If it used --batch, epg.el would need to know a passphrase even
if it is not needed (for example, it is already cached in gpg-agent,
encrypted with empty passphrase, etc.)  And also it would inhibit gpg
from doing other user queries until the gpg command terminates.

> My question now, since we understand the problem well, is if you agree
> with this plan, and if so, do you need patches from me or other
> contributors, or will you address it yourself?  There's no urgency
> implied here; I am simply trying to fix this for our users by the next
> Emacs release.

Please don't.

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>> See my earlier e-mails.  But my bigger concern is that for many users, a
>> new GnuPG release is years in the future, so even if you justify this
>> change, it won't help anyone quickly.  IMHO epg.el should work around
>> this "feature" now with the --batch --passphrase-fd options that I
>> mentioned, especially if they can work on all GnuPG versions (I haven't
>> tested that).

DU> Well, that's a design decision not to use --batch here (and probably in
DU> GPGME).  If it used --batch, epg.el would need to know a passphrase even
DU> if it is not needed (for example, it is already cached in gpg-agent,
DU> encrypted with empty passphrase, etc.)  And also it would inhibit gpg
DU> from doing other user queries until the gpg command terminates.

OK, so there's no way to avoid the broken behavior in epg.el and any
fixes on the GnuPG side have to wait until a new release (and someone,
possibly you, has to ask Werner for that fix).  Is that accurate?  It
means we should recommend to Emacs users to use GnuPG 1.x if they want
symmetric encryption to be usable (especially caching the passphrase).

>> My question now, since we understand the problem well, is if you agree
>> with this plan, and if so, do you need patches from me or other
>> contributors, or will you address it yourself?  There's no urgency
>> implied here; I am simply trying to fix this for our users by the next
>> Emacs release.

DU> Please don't.

Don't what?  I asked several questions but am clearly waiting for your guidance.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

> OK, so there's no way to avoid the broken behavior in epg.el and any
> fixes on the GnuPG side have to wait until a new release (and someone,
> possibly you, has to ask Werner for that fix).  Is that accurate?  It

Can you make a bug report about the problematic behavior (e.g. with your
previously posted recipe), and move the discussion there?


        Stefan

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Daiki Ueno]

Ted Zlatanov <tzz@lifelogs.com> writes:

> On Thu, 03 Oct 2013 10:52:46 +0900 Daiki Ueno <ueno@gnu.org> wrote: 
>
> DU> Ted Zlatanov <tzz@lifelogs.com> writes:
>>> See my earlier e-mails.  But my bigger concern is that for many users, a
>>> new GnuPG release is years in the future, so even if you justify this
>>> change, it won't help anyone quickly.  IMHO epg.el should work around
>>> this "feature" now with the --batch --passphrase-fd options that I
>>> mentioned, especially if they can work on all GnuPG versions (I haven't
>>> tested that).
>
> DU> Well, that's a design decision not to use --batch here (and probably in
> DU> GPGME).  If it used --batch, epg.el would need to know a passphrase even
> DU> if it is not needed (for example, it is already cached in gpg-agent,
> DU> encrypted with empty passphrase, etc.)  And also it would inhibit gpg
> DU> from doing other user queries until the gpg command terminates.
>
> OK, so there's no way to avoid the broken behavior in epg.el and any

Well, though you say "broken behavior in epg.el", there's clearly a
design change in GnuPG side if GnuPG 2.x behaves differently from GnuPG
1.x.

You can search on the gpg lists with something like: "gpg agent all
secret key", you will find that Werner wanted to move all the secret key
operations from gpg to gpg-agent to provide more security.  That then
ended up with that pinentry needs to be spawned by gpg-agent, not gpg.

I think most of your complaint on epg.el are user error and
misunderstanding of underlying technical concepts of GnuPG.

> fixes on the GnuPG side have to wait until a new release (and someone,
> possibly you, has to ask Werner for that fix).  Is that accurate?  It
> means we should recommend to Emacs users to use GnuPG 1.x if they want
> symmetric encryption to be usable (especially caching the passphrase).

We already recommend that.  See (info"(epa) Caching Passphrases").

GnuPG 1.x can coexists with GnuPG 2.x on a single system, and most of
distros keep both packages installable without conflict.  If you just
want to avoid the passphrase prompt, you can simply install both and epg
picks the GnuPG 1.x executable first:

(defcustom epg-gpg-program (or (executable-find "gpg")
			       (executable-find "gpg2")
			       "gpg")
  "The `gpg' executable."
  :group 'epg
  :type 'string)

>>> My question now, since we understand the problem well, is if you agree
>>> with this plan, and if so, do you need patches from me or other
>>> contributors, or will you address it yourself?  There's no urgency
>>> implied here; I am simply trying to fix this for our users by the next
>>> Emacs release.
>
> DU> Please don't.
>
> Don't what?  I asked several questions but am clearly waiting for your
> guidance.

I mean, don't add a workaround using --batch.  It's not the right
direction: breaks too many things (e.g. smartcard support) and might
even add unnecessary passphrase prompts, particularly for non-symmetric
key usage.

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Fri, 04 Oct 2013 09:12:34 +0900 Daiki Ueno <ueno@gnu.org> wrote: 

>> OK, so there's no way to avoid the broken behavior in epg.el and any

DU> Well, though you say "broken behavior in epg.el", there's clearly a
DU> design change in GnuPG side if GnuPG 2.x behaves differently from GnuPG
DU> 1.x.

DU> You can search on the gpg lists with something like: "gpg agent all
DU> secret key", you will find that Werner wanted to move all the secret key
DU> operations from gpg to gpg-agent to provide more security.  That then
DU> ended up with that pinentry needs to be spawned by gpg-agent, not gpg.

DU> I think most of your complaint on epg.el are user error and
DU> misunderstanding of underlying technical concepts of GnuPG.

I see.  I'll find a solution that works for me without epg.el so that
there will be no errors and misunderstandings.

Thank you for your help.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Thu, 03 Oct 2013 10:59:13 -0400 Stefan Monnier <monnier@IRO.UMontreal.CA> wrote: 

>> OK, so there's no way to avoid the broken behavior in epg.el and any
>> fixes on the GnuPG side have to wait until a new release (and someone,
>> possibly you, has to ask Werner for that fix).  Is that accurate?  It

SM> Can you make a bug report about the problematic behavior (e.g. with your
SM> previously posted recipe), and move the discussion there?

I don't think it's worthwhile after this discussion.  I'll work around it
and see if I can make the workaround generally available.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

> I don't think it's worthwhile after this discussion.

I think it is.  This whole discussion has been completely muddled
because it mixes up details of gpg behaviors with everything else,
whereas the only thing that really matters is the behavior of Emacs
(which depends on many more things than just gpg) and the problem there
is still unclear.

> I'll work around it and see if I can make the workaround
> generally available.

Maybe that's the best we can do, but noone will know until you report
this bug with a clear description of the undesirable behavior, so that
people can assess really what is the core of the problem and se how we
can fix it (since it surely can be fixed in many different ways at
different levels).


        Stefan

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Ted Zlatanov]

On Sat, 05 Oct 2013 12:21:35 -0400 Stefan Monnier <monnier@iro.umontreal.ca> wrote: 

>> I don't think it's worthwhile after this discussion.
SM> I think it is.  This whole discussion has been completely muddled
SM> because it mixes up details of gpg behaviors with everything else,
SM> whereas the only thing that really matters is the behavior of Emacs
SM> (which depends on many more things than just gpg) and the problem there
SM> is still unclear.

>> I'll work around it and see if I can make the workaround
>> generally available.

SM> Maybe that's the best we can do, but noone will know until you report
SM> this bug with a clear description of the undesirable behavior, so that
SM> people can assess really what is the core of the problem and se how we
SM> can fix it (since it surely can be fixed in many different ways at
SM> different levels).

I reported two bugs about the two different issues (the unavoidable
popups and `epa-file-cache-passphrase-for-symmetric-encryption').  I
did not elaborate on how unpleasant VCS interactions are because they
are just the latter bug over and over.

I am not able to develop a workaround as I hoped since my work in the
direction of implementing OpenPGP has been rejected.

Ted

Re: bad epg.el+GPG2 behavior: unavoidable passphrase pinentry prompt

[Stefan Monnier]

> I reported two bugs about the two different issues (the unavoidable
> popups and `epa-file-cache-passphrase-for-symmetric-encryption').

Thank you,


        Stefan