bug#15552: 24.3.50; epa-file-cache-passphrase-for-symmetric-encryption not respected with GnuPG 2.x

[Daiki Ueno]

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

>>> 1. On the local system, install GnuPG 2.x and don't run the gpg-agent
>>> 2. Set epa-file-cache-passphrase-for-symmetric-encryption to t
>>> 3. Open file.gpg: password dialog pops up
>>> 4. close file.gpg
>>> 5. Open file.gpg: password dialog pops up again
>>> Step (5) should not prompt.  It works properly with GnuPG 1.x.
>> That's intended behavior.
>
> Could you give the rationale for it?

When gpg-agent is not properly set up as a daemon, gpg2 invokes
gpg-agent internally for each session.  In the above case, there are two
gpg2 sessions (two "Open") and thus there are two gpg-agent processes,
which don't share the passphrase.

>> It is documented and I stated a number of times the reason and why
>> I chose such a lengthy name of the variable and the default is nil:
>
> I understand why it is nil by default, but if the user sets it to t,
> presumably he doesn't care about the fact that storing the password in
> Emacs heap is insecure.

When epg.el was written, the intention of the option was the last resort
for those who only have gpg1 and can't use gpg-agent.  Since then, I've
recommended to migrate to more secure way (i.e. using gpg-agent).

Given that gpg-agent (gpg2) is now available everywhere, I think there's
no reason to advertise the use of this variable, although at some point
a few people (afaik, only Ted) started exploiting this option to provide
degraded security for usability.

So the question is, would we really like to proactively support such a
degraded security in Emacs?