Re: Agent forwarding issue
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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
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 signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
Re: Agent forwarding issue
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 openpgp-digital-signature.asc Description: PGP signature ___ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
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
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
Agent forwarding issue
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