gpg-preset-passphrase and extra agent socket

xeyrion at gmail.com xeyrion at gmail.com
Sat Mar 25 23:56:57 CET 2023


On Fri, Mar 24, 2023 at 5:20 AM Werner Koch <wk at gnupg.org> wrote:

> On Wed, 22 Mar 2023 16:16, xeyrion--- said:
>
> > Forwarding normal socket (instead of extra socket) makes the prompt go
> > away. Is there a way to preset passphrase for extra socket as well?
>
> The caching behavior does not depend on the connection type.  Thus this
> should not be an issue.  I assume you are using 2.4.0 which has a couple
> of fixes for remote use.
>
> I am almost always using the extra-socket with cards and thus I unloch
> the card before I start working (using "gpg-card" and its "verify"
> command).
>
> I would suggest to add
>
>   debug ipc,cache
>   log-file /foo/somefile
>
> to your local gpg-agent.conf (or use watchgnupg and "socket://" as file
> for live watching) to see what's going on.  You should see some error
> message "Forbidden" when the remote site issues certain commands.
>

Thanks for the debugging tips. I collected more info using those. Caching
behavior does indeed seem to depend on connection type based on what I am
seeing in the logs:

Call to gpg-preset-passphrase for <keygrip1>:

DBG: chan_8 <- PRESET_PASSPHRASE <keygrip1> -1 <long-hex-string>
DBG: agent_put_cache '<keygrip1>'.0 (mode 1) requested ttl=-1
DBG: chan_8 -> OK

Asking to decrypt using normal socket:

DBG: chan_8 <- PKDECRYPT
DBG: chan_8 -> S INQUIRE_MAXLEN 4096
DBG: chan_8 -> INQUIRE CIPHERTEXT
DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ]
DBG: chan_8 <- END
DBG: agent_get_cache '<keygrip1>'.0 (mode 2) ...
DBG: ... hit

Asking to decrypt using extra socket:

DBG: chan_8 <- PKDECRYPT
DBG: chan_8 -> S INQUIRE_MAXLEN 4096
DBG: chan_8 -> INQUIRE CIPHERTEXT
DBG: chan_8 <- [ 00 00 00 ...(105 byte(s) skipped) ]
DBG: chan_8 <- END
DBG: agent_get_cache '<keygrip1>'.1 (mode 2) ...
DBG: ... miss
DBG: agent_get_cache '<keygrip1>'.1 (mode 2) (stored cache key) ...
DBG: ... miss
starting a new PIN Entry


The difference seems to be that normal socket uses ".0" as cache key while
extra socket uses ".1" and therefore misses?

This is using GnuPG 2.4.0 both on local and remote.

Ideas? Is this a designed behavior? Or do I have something misconfigured?

Thank you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20230325/9d8b72b2/attachment.html>


More information about the Gnupg-users mailing list