Thanks. Fixed in stanble and master.

This was already fixed with version 2.2.5.

This was also raised for (hopefully) wider discussion on the IETF mailing list.

I am in charge of editing the current OpenPGP draft, so I will for sure keep an eye on that issue. If would appreciate if you can post your report also to openpgp at ietf org.

Thanks, fixed in master.

I disabled the dependency rules for the figures (it's only enabled for maintainers).

Given the recent problems with the keyservers, I expect that the keyserver feature will go away anyway and thus I do not think we will put any more effort into this. Thus I re-tag this as gpg 2.3.

If we only need it for backward compatibility, then the configuration in gpg.conf should *not* be overriding the preferred, forward-looking form of the configuration (in dirmngr.conf). If it is low priority to fix this, then there will be a generation of GnuPG users and toolchains which deliberately configure the value in gpg.conf instead of dirmngr.conf because they'll know that's the more robust way to do it.

We need --keyserver in gpg for just one reason: backward compatibility.

thanks for fixing that error message, @werner. As @Valodim points out in discusson about hagrid, a gpg.conf keyserver option (deprecated according to the documentation) overrides the dirmngr.conf keyserver option (not deprecated according to the documentation.

I see the regression of gpgconf. I wonder if it's better to fix gpgconf side, too.

I see a regression with your fix. This option is even controllable with gpgconf at the basic level. It would be better to make it a dummy option.

I meant, 'card-timeout' was not intended for controlling caching PIN on card. It was for "DISCONNECT" command support.
I'm going to remove questionable documentation.
Closing.

No worries -- you led me in the direction of a solution when you mentioned loopback mode. I appreciate your time and your help!

Thank you for your fix suggestion. I think your change is good. I applied and pushed.

Sorry, I responded in a mode of "tracking a bug to fix soonish". I should have changed my mode into showing HOWTO.
Thanks for sharing useful link.

This is problem of your setup of your build environment. Closing.

We got reports from Ubuntu users, perhaps, it's good to refer:

The behaviour related to ssh key access is due to the way ssh works: After a connection has been established to a server ssh presents to to the server all identities (public keys) it has access to (meaning it has a corresponding private key). Thus we can't tell ssh all the keys we have because that would be an information leak and may also take too long. Because the user may in some cases not want to use the ssh-agent but resort to ssh command line input of the passphrase, we do not insist on using a key known by gpg-agent.

Thanks

I removed this specialized error message. Thanks for reporting.

Users keep showing up in our support, confused by this inconsistency. This problem continues in 2020. What's holding this back?

Paul Wouters writes to me:

One of the things that dirmngr has going for it is that it tracks the current network state, and it would be nice to be able to reuse that state across sessions. If an ephemeral keyring can't use a shared dirmngr, there are fewer arguments for having dirmngr in the first place, and people might be more justified in replacing it with things like https://gitlab.com/anarcat/scripts/blob/master/openpgp-key-get

I don't anymore think this is a high priority request. BTW, A more real problem than several dirmngr instances is multi-user access to smartcards.

Thanks.

Sure, but lets use that ticket for this. if you have another topic, feel free to open another ticket.

Is a PR to add it to the website welcome? Not sure that I'll get around to it, but in case someone else is interested - I linked here from those stackoverflow pages.

It is in the tarball:

doc/DETAILS

and for example Debian installs it as /usr/share/doc/gnupg/DETAILS.gz. Check out the first section "Format of the colon listings". Or use GPGME which provides C, C++, Python and JSON bindings. Sorry, it never made it to the website.

@werner where is this now documented? I can't find it.

First of all I find PIN a very bad term. "Personal Identification Number" for example for my Gnuk token is confusing. I use a string there,... So let us use PIN only where it really has to be a number. Otherwise it is a Password.

Despite that I created this task, I am still not not convinced that removing the term passphrase is a good idea. If we do this in gnupg we would need to change all strings to make it clear that the passphrase is used to protect one's own key and has nothing to do with encryption etc. In fact the term PIN would be better because it is common knowledge that you use a PIN to get access to something you own. There would be less confusion on the purpose of the passphrase. Sure PIN is usually considered to be a number. However my bank allows a string to be used as, what they call, PIN.

There has been some progress here. At least we no longer use "passphrase" in new code. We still have not yet replaced all old occurances.

Fixed. Thanks.

T4298: 'make check' with uninstalled library, which is building now (even if rpath doesn't work well) handles related issue, which was fixed for libgcrypt-1.9. Since this issue is for other libraries (libgpg-error, specifically), we could do something similar, but, it may be detecting LD_LIBRARY_PATH to fail with "Please remove LD_LIBRARY_PATH".

It seems it's Ubuntu specific: https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1796563

I think that all that we can do is to improve documentation.

yes. that's why i wrote it in '['-brackets.
but usually, in info-documents a synopsis is written about it.
I think that it's not self-evident, that "you can either give a file or let the tool read from stdin or output to stdout" and therefore should be written explicitly.

Could you say, on which platforms exactly it should work?

no-grab does only work on certain platforms. Thus this is no bug.

"partially" means it doesn't allow to input elsewhere, but in case of focus loose input will go nowhere

At least it MUST NOT grub input with no-grab option. But it doesn't allow to input elsewhere in any case.

We know that. And pinentry-gtk does like that.

It's possibe to do via gtk3 directly:
https://developer.gnome.org/gtk3/stable/gtk3-General.html#gtk-device-grab-add

Yes. It's up to GCR library in GNOME.

@werner Given you filed it as low priority and documentation - could you give feedback on whether that is expected behaviour or not?