Page MenuHome GnuPG

pin entry prompt should include more structured metadata
Closed, ResolvedPublic


Gnome Keyring (GKR) currently proxies all communication with gpg agent. Because
GKR's implementation of the state machine is incomplete, this prevents a lot of
functionality from working correctly. For instance, it is not possible to use a
smart card. (Further, this is basically a MITM attack.)

The maintainer of GKR (Stef) has confirmed that the only reason they intercept
the communication with gpg agent is to be able to cache the passphrase. This
could instead be done by having a GKR-aware pin entry program. When gpg agent
needs a password, it invokes the pin entry program as usual and the pin entry
can consult GKR before prompting the user for a password. If the password is
not cached, the pin entry program can save it with GKR.

For this to work, GKR needs a stable identifier. Currently, this is what the
prompt looks like:

OPTION ttyname=/dev/pts/1
OPTION ttytype=xterm-256color
OPTION lc-ctype=en_US.UTF-8
OPTION lc-messages=en_US.UTF-8
OPTION default-ok=_OK
OPTION default-cancel=_Cancel
OPTION default-prompt=PIN:
OPTION touch-file=/data/.gnupg/S.gpg-agent
SETDESC You need a passphrase to unlock the secret key for user:%0A"Stef

Walter <>"%0A1024-bit DSA key, ID D92765AF, created 2002-01-24%0A

  SETPROMPT Passphrase
  SETERROR Invalid passphrase; please try again

What is needed is an OPTION that indicates the key's fingerprint or some other
stable identifier identifying the context.

Also see



Event Timeline

werner removed a project: Bug Report.
werner added a subscriber: werner.

For a regular private key wie have such an indentifier. We don't have it for
symmetric passphrases but they are very rarely used. There is also no need to
have any cache for a smart card PIN.

The OpenPGP information as conveyed with SETDESC ist not a stable idnetification
but I think I can add something else. Not for 2.1.3 but soon after it.

Well, I commited a change to gnupg and for documentation reasons also to pinentry.

When calling pinentry with a known key (but not for PIN or during key creation)
the internal cache id is converted to a keyinfo string and send to Pinentry.

  SETKEYINFO n/FD692BD59D6640A84C8422573D469F84F3B98E53

That string identifies a key. It is prefixed with a letter with a secret
meaning (actually n = normal key, s = used for ssh). Pinnetries should not
interpret the string but take it as opaque data.

It is possible to backport this to 2.0 if there is an interest in 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.

neal claimed this task.
neal removed a project: Testing.