Re: Agent forwarding issue
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
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 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
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
Is there a way to forcefully re-enable allow_external_password_cache under KDE
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) Regards, Mike OpenPGP_0xCB9123D02A51C1D3.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
