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 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
