[Pkg-gnupg-maint] Bug#764068: gnupg-agent: use standard socket by default

[Paul Fertser]

Package: gnupg2
Version: 2.0.26-3
Severity: wishlist

Hello,

GnuPG2 currently offers two different schemes of using gpg-agent, the key
management daemon. The first method is the one extensively described in the
man page and elsewhere, suggesting specific way of starting gpg-agent on
user session's startup and exporting some appropriate environment
variables. When gpg2 is trying to contact the daemon but it's not
available, it starts it automatically for a one-shot operation (with the
--server option), and gpg-agent exits after performing the desired
operation, no key caching takes place, so all the corresponding TTL options
are ignored.  This is the default in the current Debian package. The second
method is to use a standard gpg-agent socket location; in this case gpg2
starts the agent on demand (as in the previous case) but leaves it running
in daemon mode, and so it continues to serve requests from all the
applications via the standard socket location, in a transparent and
automatic manner, without requiring user to set any environment variables.
This second method can be forced with the current package by adding
use-standard-socket option to ~/.gnupg/gpg-agent.conf.

My proposal is to add --enable-standard-socket to the configure flags to
make the second method default.

Rationale:

The second method is considerably more user-friendly as it doesn't require
any explicit configuration, works universally (no difference between an X
session and the usual console session), and so always produces the expected
results. It's also the way the upstream is heading as the configure-time
option --enable-standard-socket was made default in
002b30e75c623d15e89708a27442836bdf038ebc (gnupg-2.0.13-178-g002b30e, it's
in the 2.1 dev branch forked shortly after v2.0.13 thus not present in any
of 2.0.x versions; first found in gnupg-2.1-base~20) and was completely
removed in 9c380384dafb213334f8834178c5ceb0bf33db6e
(gnupg-2.1.0-beta834-22-g9c38038) in favour of always using the standard
socket (so the Debian users will have to migrate to this new method sooner
or later anyway).

TIA