Wed, Jul 17
Tue, Jul 16
Thanks, fixed in master.
Mon, Jul 15
Sun, Jul 14
Fri, Jul 12
I disabled the dependency rules for the figures (it's only enabled for maintainers).
Fri, Jul 5
Thu, Jul 4
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.
Wed, Jul 3
Jun 18 2019
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.
Jun 8 2019
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.
Jun 6 2019
Jun 4 2019
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.
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.
Jun 3 2019
This is problem of your setup of your build environment. Closing.
We got reports from Ubuntu users, perhaps, it's good to refer:
May 21 2019
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.
May 17 2019
May 15 2019
May 14 2019
I removed this specialized error message. Thanks for reporting.
May 2 2019
Users keep showing up in our support, confused by this inconsistency. here's the most recent ones:
Apr 25 2019
Apr 23 2019
Apr 19 2019
Paul Wouters writes to me:
Apr 10 2019
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
Apr 9 2019
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.
Mar 25 2019