So your solution is fine and produces the same result as a new option. Okay to
close?

What about adding an option to not embed the filename even if a file name was
given? It can be hard to convince other tools (e.g. enigmail) to use pipes for
just some of the operations ("cat %f | gnupg" for encryption, but not for
decryption). My workaround with --set-filename "" did not lead to problems yet,
so maybe this is good enough, from a usability point of view. Also, I just had a
look into RFC4880, and it seems that zero-length filenames are perfectly OK:
"This may be a zero-length string."

1.4 won't handle such a redirection because it does not use libassuan.

2.0 should follow such a redirection but the 2.0 agent is not able to setup a
socket in this way. If there is a real need it can be backported.

Thanks for the feedback. Closing.

Looks like the actual issue was that gpg-agent wasn't running.

Works fine now. Thanks for your help.

gpg agent already handles caching passwords in memory; Gnome keyring is just
used to cache the passwords on stable storage. Thus, I think the current
behavior is correct. If you disagree, please reopen and describe the behavior
that you expect.

Note: to have gpg agent cache passwords for a long time, set default-cache-ttl
and max-cache-ttl in your gpg-agent.conf to large values. To make sure the
cache is cleared when you log out, use 'gpgconf --reload gpg-agent' (or use send
SIGHUP to the right gpg-agent).

So the implication here is that users who want to use XDG_RUNTIME_DIR can do:

echo '%Assuan%' > ~/.gnupg/S.gpg-agent
echo '${XDG_RUNTIME_DIR}/S.gpg-agent' >> ~/.gnupg/S.gpg-agent

and it will Just Work for those with an NFS homedir?

Even on non-NFS volumes, this has the nice property that gpg-agent's
"check-own-socket" feature should be able to close down the gpg-agent process
when it's no longer needed by an active session.

What would the failure conditions be if that variable isn't actually set,
though? I guess it would be the same as specifying /S.gpg-agent, which should
result in permission denied, which means a failed gpg-agent. Is that right?

Will 1.4.x or 2.0.x respect such a redirection if they find it in the socket
they're trying to talk to, or is this a 2.1.x-only feature?

Done with commit 9bca96d. Here is how to use it:

  $ gpg-connect-agent 
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  OK
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 83886179 Operation cancelled <Pinentry>
  > passwd --verify 2C1103C5C84AAD061B5E3221C048A93D878F7EEE
  ERR 67108875 Bad passphrase <GPG Agent>

For the OK I entered the correct passpharse, for the bad passpharse I entered a
bad passphrase three times in a row.

We can already do a dummy signature, but it feels sloppy for several reasons:

• it's not clear exactly what to sign with a dummy signature -- should you sign

static text or a dynamic (random) block?

• it's not clear what to do with the signatures after creation. It's

concievable that a dummy signature could be abused/misused if the material being
signed turns out to have some other meaning.

• gpg-agent can be configured to log to an append-only file as a means of

monitoring what signatures have ever been made by a given key. Dummy signatures
introduce spurious signing events that are indistinguishable from real
signatures in this log

• the creation of arbitrary signatures takes more time than testing passphrase

and returning feedback.

Why not doing a dummy signing then?

Thr redirect feature has not yet been documented. You can create a regular file
with the name of the socket file using this format

   %Assuan%
   socket=NAME

   where NAME is the actual socket to use.  No white spaces are
   allowed, both lines must be terminated by a single LF, extra lines
   are not allowed.  Environment variables are interpreted in NAME if
   given in "${VAR} notation; no escape characters are defined, if
   "${" shall be used verbatim, you need to use an environment
   variable with that content.

   The use of an absolute NAME is strongly suggested.  The length of
   the file is limited to 511 bytes which is more than sufficient for
   that common value of 107 for sun_path.

and to be clear, I'm not suggesting not using ~/.gnupg at all anymore. I'm only
saying that using that as a default location for gpg-agent socket is bad for some
use-cases (like nfs $HOME)

what is this "redirect feature" you mention? how would that help a user logging
into multiple computers using the same (nfs) $HOME ?

Using ~/.gnupg as gnupg's home directory predates XDG by many years and thus
would be an incompatible change. NFS is not a problem due to thre redirect feature.

Thanks for forwarding.

Followup details about XDG_RUNTIME_DIR if you're not familiar, see:
http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

"$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-
essential runtime files and other file objects (such as sockets, named pipes,
...) should be stored. The directory MUST be owned by the user, and he MUST be
the only one having read and write access to it. Its Unix access mode MUST be
0700.

The lifetime of the directory MUST be bound to the user being logged in. It MUST
be created when the user first logs in and if the user fully logs out the
directory MUST be removed. If the user logs in more than once he should get
pointed to the same directory, and it is mandatory that the directory continues
to exist from his first login to his last logout on the system, and not removed
in between. Files in the directory MUST not survive reboot or a full logout/login
cycle.

The directory MUST be on a local file system and not shared with any other
system. The directory MUST by fully-featured by the standards of the operating
system. More specifically, on Unix-like operating systems AF_UNIX sockets,
symbolic links, hard links, proper permissions, file locking, sparse files,
memory mapping, file change notifications, a reliable hard link count must be
supported, and no restrictions on the file name character set should be imposed.
Files in this directory MAY be subjected to periodic clean-up. To ensure that
your files are not removed, they should have their access time timestamp modified
at least once every 6 hours of monotonic time or the 'sticky' bit should be set
on the file.

If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement
directory with similar capabilities and print a warning message. Applications
should use this directory for communication and synchronization purposes and
should not place larger files in it, since it might reside in runtime memory and
cannot necessarily be swapped out to disk."

Done with commit 010d26a for 2.1.6

Fixed in 2.0.28 (and in 2.1.x).

Hm, you make a good point about this being undesirable in the general case --
access to a normal gpg-agent shouldn't provide an attacker with a way to guess
passwords silently.

However, consider the mailpile case -- where gpg-agent is running on the
webserver, and the login webpage wants to verify a given user based on the
password for the user's secret key (and wants to avoid keeping some extra
/etc/shadow-equivalent file lying around).

Maybe such an application would start gpg-agent in a different/simpler mode? Or
should we recommend that such an application test the provided passphrase in
some other way, without using gpg-agent at all?

Does encrypt-to/hidden-encrypt-to in gpg.conf do this?

This feature has landed in the latest 2.0 and 2.1 branches and support has been
added in pinentry. I'm closing this now.

Hi dkg,

On the mailing list and in T1928, we discussed
why it shouldn't be possible for a program to pass the passphrase to gpg agent.
This feature request is at odds with the conclusion drawn there. Should this
issue be closed as WONTFIX?

Thanks,

:) Neal

Done with commit 25331bb for 2.1.5.
Won't be backported to 2.0 or 1.4.

This also changes the publication date to the date of the last commit for one of
the texi files. This was the original intention of the version.texi file but
that did not worked in a git world.

This also extends to keys stored on smartcards, see
https://lists.gnupg.org/pipermail/gnupg-devel/2015-June/029959.html

Won't be done for 2.0 but I will try to implement that for 2.1

Did you asked on the GUIX list whether they have a similar problem?

Oh well, resizing the buttons to a new fixed size would be a job in the source
of 10 minutes or so. However, this makes an very ugly Pinentry for every day's
use (i.e. entering a passphrase for an existing key). So, sorry, I won't take
that patch.

With native Windows code I mean native Windows code for GUIs instead of relying
on MFC or whatever is the latest GUI framework MS uses. This is similar to xlib
programm vs. GTK+ programming

Anyway, thanks for looking into this. I will retitle the bug to keep it open.
Maybe eventually someone starts to hack on it.

That might be possible. However outstarting gpg-agent won't be implemented for 1.4.

On Mon, May 18, 2015 at 10:37:08AM +0000, Werner Koch via BTS wrote:

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

Exactly this thing I reported as a workaound. I'd like to see working gpg
without setting the GPG_AGENT_INFO variable before.

Please start gpg-agent manually (gpgconf --launch gpg-agent) and set a fixed
GPG_AGENT_INFO envvar in your login script.

I tested your pkg-config patch on Debian Jessie and everything still compiles
fine. I've applied the pkg-config patch. If gentoo is now using a newer
version of this patch, please let me know. Thanks.

Fixed in edd9a88.

This is about updating the docs. Will be done for 2.1 only.

This reminds me that we don't have a mail keyserver in 2.1 yet. Need to
evaluate whether it will be useful.

(funny due date removed)

Lot of things pertaining to keyservers changed in the meantime and we have a
couple of other things in mind as well.

Yes, auto-detection in dirmngr-client would be great, thanks!

Is this still a problem?