Mailing List Archive

gpg-preset-passphrase and extra agent socket
Hello,

I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local agent.

Forwarding normal socket (instead of extra socket) makes the prompt go
away. Is there a way to preset passphrase for extra socket as well?

If not, what are the implications of forwarding the normal socket? The wiki
page just says "extra socket is more restricted" without going into any
details.

Thank you.
gpg-preset-passphrase and extra agent socket [ In reply to ]
I am trying to set up agent forwarding as per
https://wiki.gnupg.org/AgentForwarding. Everything is generally working,
but the remote gpg is prompting for passphrases
despite gpg-preset-passphrase having been used against local gpg agent.

Forwarding normal socket (instead of extra socket) makes the prompt go
away. Is there a way to preset passphrase for extra socket as well?

If not, what are the implications of forwarding the normal socket? The wiki
page just says "extra socket is more restricted" without going into any
details.

Thank you.
Re: gpg-preset-passphrase and extra agent socket [ In reply to ]
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.

> If not, what are the implications of forwarding the normal socket? The wiki
> page just says "extra socket is more restricted" without going into any

For example the remote site can't list the keys on the local site. This
is sometimes required and thus you can allow this on per private key
base by adding

Remote-list: true

to the private key file (which you figure out using gpg -K
--with-keygrip). But that might not be your problem.


Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: gpg-preset-passphrase and extra agent socket [ In reply to ]
On Fri, Mar 24, 2023 at 5:20?AM Werner Koch <wk@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.
Re: gpg-preset-passphrase and extra agent socket [ In reply to ]
On Sat, 25 Mar 2023 18:56, xeyrion--- said:

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

You are right. I forgot about this.

You need to wait for the next version or apply the attached patch and
run gpg-preset-passphrase with the option --restricted to address the
other cache.


Shalom-Salam,

Werner


--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein
Re: gpg-preset-passphrase and extra agent socket [ In reply to ]
On Mon, Mar 27, 2023 at 5:58?AM Werner Koch <wk@gnupg.org> wrote:

> You are right. I forgot about this.
>
> You need to wait for the next version or apply the attached patch and
> run gpg-preset-passphrase with the option --restricted to address the
> other cache.
>

Great, thanks for confirming and the patch!