Jul 18 2019
I'm aware of you releasing an RC for comments, and i apologize for not catching this particular case earlier. As you know from T4607, i was even advocating for it. i didn't understand the full implications of the "import-then-clean" approach at the time, and was thinking it would only apply to the incoming material, not the stored material.
The code has comments why we do a first clean_key on the imported keyblock.
i've merged a variant of rGbe99eec2b105eb5f8e3759147ae351dcc40560ad into the GnuPG packaging in debian unstable as of version 2.2.17-3 to avoid the risks of data loss and signature verification failures. I'll revert it if i see the concern addressed upstream.
Jul 16 2019
that pseudocode is strange to me -- it looks like you have (two) duplicate calls to clean_key (imported_keyblock) (though maybe i just don't know what .... means in this pseudocode).
You are partly right. I missed that we also do clean the original keyblock while updating a key. The code is
Jul 15 2019
I think dropping import-clean from the default keyserver options is the right way to go. It is not clear what additional benefit import-clean provides given that we are already using self-sigs-only. And the idea of non-additive behavior to the local keyring when pulling from a keyserver is a deeply surprising change for multiple users i've talked to.
Jul 14 2019
Jul 10 2019
Ah, that makes sense, good catch. Seems this is just an issue of documentation, then.
We should put it of the agenda od the Brussesl summit in 3 weeks. I have a few ideas what we can do in gpg.
Jul 4 2019
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.
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.
May 27 2019
I doubt that we are going to implement this.
May 17 2019
May 15 2019
May 14 2019
I removed this specialized error message. Thanks for reporting.
This is particularly bad for users who have manually specified a given keyserver in dirmngr.conf, because even a transient failure in that keyserver will prevent them from any future keyserver requests until dirmngr decides that the "death" has worn off.
Apr 1 2019
HTTP/1.1 spec, RFC 7230, Section 5.4, paragraph 2:
Please be so kind and point me to the specs stating that you should put the IP address into Host:
It's up to GPG to send the Host header that shows the user's intent.
So in short you want:
- Allow to specify a keyserver by IP without any DNS lookups.
- When connecting via IP use the IP address for Host:.
Mar 31 2019
Mar 13 2019
There is a solution for it:
Feb 9 2019
So, the keyserver operator had thrown in a hockeypuck server in the pool, causing this.. While the keyserver remains in the exclude list until confirmation it has been resolved, that explains the behavior and it has been made clear that separate software needs to use different names in the future.
Feb 4 2019
@kristianf we talked about this on Saturday evening. Would you be so kind and have a quick look at the problem with the hu server?
Feb 1 2019
Hi Werner and thanks for looking into this.
Jan 30 2019
According to sks-keyservers.net both servers you mention run the very same software. Thus I would like to understand why you think they require the use of a legacy option.
Oct 29 2018
It actually tries several servers but we need to set a limit because we need to cope with longer timeouts. Do you suggest to toggle between v4 and v6 addresses? That is if a v6 address fails, first try the next v4 address and it that fails, another v6 address, etc.
Oct 2 2018
The problem is that the keyserver network is abused as free and
permanent data storage. We can't do much about it without larger
changes on the search capabilities of the keyservers. For more
information see the archives of the sks-devel list starting in July.
Oct 1 2018
Ok. I was not aware that HKPS should already have the highest quality.
hkps pool really should be the most responsive, and it already requires clustered only servers for a couple of weeks to try to increase the responsiveness. Experience has shown that any keyserver with less than 3 nodes in a cluster should not be used towards end-users. But do you have any more debugging output as to the problem at hand?