Mailing List Archive: Agent forwarding issue

Agent forwarding issue

Apr 4, 2024, 9:04 PM

Post #1 of 8 (115 views)

Hi,

I have been working on setting up agent forwarding?.

One issue which I have not yet found a solution for is that
gpg prints the following to stderr when performing actions
involving the agent:

gpg: problem with fast path key listing: Forbidden - ignored

Both hosts are running gnupg-2.4.5, based on the Fedora
packages.

With mutt, this causes the signing to pause after entering
the password, as stderr is not empty (I think this is the
reason, anyway). Can this warning be avoided or silenced
(without directing stderr to /dev/null)?

I can't find much information about it, but it seems like
while this is something useful to note, after seeing it once
it is simply needless.

I believe this is because I've used the extra socket, which
seems like the proper thing to do with agent forwarding, but
perhaps isn't worth the hassle? I'm not too eager to
forward the regular agent when I can use a more restricted
socket.

? https://wiki.gnupg.org/AgentForwarding

Thanks,

--
Todd

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 5, 2024, 1:59 AM

Post #2 of 8 (115 views)

Permalink

Hi!

> gpg: problem with fast path key listing: Forbidden - ignored

I'll suppress that message in --quiet mode for the next release.

When doing a secret key listing (which happens with -K but also in
--with-colons mode) gpg walks over all public keys and asks the agent
for each key whether a corresponding secret key exists. With many
secret keys this is quite some overhead and thus gpg first tries to a
get a listing of all secret keys (the keygrips) and later can do a fast
memcmp instead of an IPC call.

If you use the extra-socket certain operations are forbidden so that a
rogue gpg version on the remote site won't be able to change passwords,
export secret keys, or get a listing of all available secret keys. This
is why you see this diagnostic.

Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 5, 2024, 10:03 AM

Post #3 of 8 (115 views)

Permalink

Hi Werner,

Werner Koch via Gnupg-users wrote:
>> gpg: problem with fast path key listing: Forbidden - ignored
>
> I'll suppress that message in --quiet mode for the next release.

Excellent, thanks!

> When doing a secret key listing (which happens with -K but also in
> --with-colons mode) gpg walks over all public keys and asks the agent
> for each key whether a corresponding secret key exists. With many
> secret keys this is quite some overhead and thus gpg first tries to a
> get a listing of all secret keys (the keygrips) and later can do a fast
> memcmp instead of an IPC call.

In theory, would this not occur if I cleaned up the keyring
a bit. I've got ~350 public keys. Some are likely expired
or no longer useful.

This is without any sort of auto-key-locate enabled -- just
years or accumulating keys. It doesn't _seem_ like that
many keys to have around...

> If you use the extra-socket certain operations are forbidden so that a
> rogue gpg version on the remote site won't be able to change passwords,
> export secret keys, or get a listing of all available secret keys. This
> is why you see this diagnostic.

I manage the remote system and consider it reasonably
secure, to the extent any online system can be call
"secure." It's not much less secure than the system from
which I am forwarding, other than that I'm not physically
beside it.

In such a case, it sounds like it may be reasonable to use
the normal socket? Until the remote side is updated to
silence this via --quiet, at least.

I saw you pushed the change already, so I applied it to the
build on the remote host and can confirm it does the trick.

Thanks for the quick reply, fix, and additional details!

Cheers,

--
Todd

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 5, 2024, 10:39 AM

Post #4 of 8 (115 views)

Permalink

In the mean time, you could put something along the lines of:

{CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
listing: Forbidden - ignored$" or something, to keep that output out
of your stderr stream.

If something else unexpected displays, you'll get more issues, but
then you probably want to know if / when / should that happen.

If you add --quiet now, even when the change below happens later, your
script above won't need to change again.

On Fri, Apr 5, 2024 at 5:01?AM Werner Koch via Gnupg-users
<gnupg-users_at_gnupg.org_omcujl92@duck.com> wrote:
>
> Hi!
>
> > gpg: problem with fast path key listing: Forbidden - ignored
>
> I'll suppress that message in --quiet mode for the next release.
>
> ...

On Fri, Apr 5, 2024 at 11:24?AM Mike S wrote:
>
> Hello,
>
> is there a way to (re-)enable password storage and retrieval via secret service under KDE?
>
> The allow_external_password_cache option was disabled in this ticket:
> https://dev.gnupg.org/rPefb6de7fb2c15c1e31349b80fa7c8c1d4694c6cf
>
> But for me it would be useful to override this setting, I'm not using KWallet as my secret-service (I'm using KeePassXC), and are not affected by the possible deadlock.
> I thought about somehow changing the XDG_SESSION_DESKTOP env variable that pinentry-gtk-2 sees, but I don't think I can do that (because gpg-agent is launching pinentry?)
>
>
> Currently I downgraded the pinentry version.
> My problem is, that I sign my git commits and now I have to write my passphrase every time I commit.
> (With version 1.2.1-3 it takes the passphrase out of my KeePass database)

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 5, 2024, 1:59 PM

Post #5 of 8 (115 views)

Permalink

Bee via Gnupg-users wrote:
> In the mean time, you could put something along the lines of:
>
> {CmdCalls ; } 2>&1 | grep -v -e "^gpg: problem with fast path key
> listing: Forbidden - ignored$" or something, to keep that output out
> of your stderr stream.

I think there's a downside to that (but I could always be
wrong). Redirecting stderr to stdout would prevent mutt (or
whatever tool was using being used) from being be able to
display output only from stderr. That is helpful when the
exit status is 0 but there were warnings, as in this case.

> If something else unexpected displays, you'll get more issues, but
> then you probably want to know if / when / should that happen.
>
> If you add --quiet now, even when the change below happens later, your
> script above won't need to change again.

Indeed, if Werner weren't so quick, perhaps I would have
considered some sort of adjustment. Though I try to use the
mutt's contrib/gpg.rc unaltered so I don't have to remember
to merge in fixes they make there.

This does remind me that I should re-evaluate using gpgme
as the backend. I don't recall why I disabled that now. It
may have been for an issue which is long-since resolved. ;)

--
Todd

_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
https://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 7, 2024, 11:47 PM

Post #6 of 8 (111 views)

Permalink

On Fri, 5 Apr 2024 13:03, Todd Zullinger said:

> In such a case, it sounds like it may be reasonable to use
> the normal socket? Until the remote side is updated to

In fact, I also did this for some time but later came up with

CommitDate: Wed Oct 12 11:30:35 2022 +0200

agent: Introduce attribute "Remote-list" to KEYINFO.

* agent/command.c (do_one_keyinfo): Add arg list_mode. Check
attribute Remote-list.
(cmd_keyinfo): Change semantics to return nothing in restricted list
mode.

which is

*** Remote-list
Allow to list the key with the KEYINFO command from a remote machine
via the extra socket. A boolean value is expected; the default is
"no". Note that KEYINFO will anyway provide information if the
keygrip is specified.

Not exactly your problem but somehow related.

Salam-Shalom,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 10, 2024, 9:15 AM

Post #7 of 8 (92 views)

Permalink

Hi,

Werner Koch via Gnupg-users wrote:
> On Fri, 5 Apr 2024 13:03, Todd Zullinger said:
>
>> In such a case, it sounds like it may be reasonable to use
>> the normal socket? Until the remote side is updated to
>
> In fact, I also did this for some time but later came up with
>
> CommitDate: Wed Oct 12 11:30:35 2022 +0200
>
> agent: Introduce attribute "Remote-list" to KEYINFO.
>
> * agent/command.c (do_one_keyinfo): Add arg list_mode. Check
> attribute Remote-list.
> (cmd_keyinfo): Change semantics to return nothing in restricted list
> mode.
>
> which is
>
> *** Remote-list
> Allow to list the key with the KEYINFO command from a remote machine
> via the extra socket. A boolean value is expected; the default is
> "no". Note that KEYINFO will anyway provide information if the
> keygrip is specified.
>
> Not exactly your problem but somehow related.

Neat. I have probably read agent/keyformat.txt before, but
not in a long time and I never had any reason to consider
editing the .key files.

This caused me to re-read the document and I'll likely add
an additional Token: line to note the two cards which hold a
new key (which I have yet to start using). That should make
it easier to move between the cards, it sounds like.

In the process, I spotted a few minor typos and sent a patch
to gnupg-devel.

Thanks again, Werner!

--
Todd

Re: Agent forwarding issue [ In reply to ]

gnupg-users at gnupg

Apr 10, 2024, 11:25 PM

Post #8 of 8 (92 views)

Permalink

On Wed, 10 Apr 2024 12:15, Todd Zullinger said:

> This caused me to re-read the document and I'll likely add
> an additional Token: line to note the two cards which hold a
> new key (which I have yet to start using). That should make

That is actually there (TOKEN, see the example) and gpg-agent updates
the file if it find another card with the same key. See for example
https://dev.gnupg.org/T6135 . However, you are free to edit/add such
entries.

Talking about keyformat.txt: I think it is time to move that over to
doc/ where people would expect it.

Shalom-Salam,

Werner

--
The pioneers of a warless world are the youth that
refuse military service. - A. Einstein

Mailing List Archive

Attached Files:

Attached Files:

Attached Files:

Attached Files: