The sks pool is now officially gone.
Jun 21 2021
Jan 28 2021
The last server of the HKPS pool dropped off for several hours yesterday, during which hkps.pool.sks-keyservers.net could not be resolved.
Dec 4 2020
Perhaps of interest for this issue: the HKPS pool has consisted of only a single server for a couple of months now.
Jul 5 2020
I'd be interested, is this is still on the agenda?
Mar 10 2020
Werner said that it's possible in OpenPGP to also put the pubkey into the signature. (...) The nice advantage is that this will also work for files.
Feb 19 2020
But searching on Keyservers is also in my opinion not a common use case for Kleopatra users.
I can attest to the "growing bit of popular lore": Roughly half the support requests I get to firstname.lastname@example.org boil down to an exchange of "it just doesn't work with a 'general error' message" -> "try killall dirmngr" -> "that did it". I have heard similar stories from @patrick from Enigmail users, and more than once heard people applying poweruser trickery like "I just have killall dirmngr in my resume.d".
Jan 20 2020
that does look like your host can resolve domains for ipv6 addresses, but can't actually connect to them. what does host keys.openpgp.org say? And ip a?
Jan 19 2020
but keys.openpgp.org resolves only to a v4 address.
Dec 10 2019
That sounds like you might have a different issue in mind?
Nov 8 2019
Sorry, I don't know which source code comment you are referring to. You mention the comment at https://dev.gnupg.org/T4628#128529 as well, but neither this commit nor be99eec2b105eb5f8e3759147ae351dcc40560ad contain such comment.
Nov 7 2019
I'm confused by this commit: Third-party sigs were the ones used for flooding, and those are dropped with self-sigs-only. Is the additional clean operation still necessary for the mitigation? Wouldn't it be easier to just not set the import-clean flag in the first place for the default keyserver options?
Oct 17 2019
GnuPG ships a non-PKI certificate, specifically to authenticate hkps.pool.sks-keyservers.net. Now due to an implementation detail, this has been shown to potentially lead to authentication of other domains by this certificate, if a maintainer changes the default keyserver via the DIRMNGR_DEFAULT_KEYSERVER variable in configure.ac. Now arguably, this variable isn't exposed via ./configure, so it's not "officially" configurable - but evidently maintainers do want to change it. A trivial one-line patch was supplied to change the unintended and potentially security-problematic behavior into the (I believe) obviously intended one.
Jul 19 2019
So, what about this? If I recall correctly, we had agreed in the call to merge this patch, at least into master?
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 5 2019
and from my understanding they are sending the self-signatures anyway.
Jul 2 2019
Done. Hopefully this works now :)
Which is a bad idea because CBC is still a very common cipher mode.
Jun 24 2019
It's been a while, any word on this? I sent the DCO as requested. Are there any technical concerns left to address?
Jun 21 2019
A possible exception here is that .onion TLDs should stick with HKP by default
May 10 2019
Apr 5 2019
I disagree that it's conceptionally the same, unless you also consider any key on an HTTP server to be "conceptionally the same" as WKD.
Certain origins do have special treatment but in general the key origin is meta data for the frontend.
Apr 4 2019
I'm a bit confused. The origin of Autocrypt keys is clearly different from keyservers ("ks"), why would they use the same value? I was aware that origin values are mapped to integers, but your description seems to imply that these integers have significant ordering in terms of trust. The documentation in the man page is a bit bare bones, but my interpretation of "key-origin" was that it simply stated the method of discovery for a key, leaving any implications of trust to the client. Is this incorrect?
Nov 8 2018
Fair enough. Let's wait and see what others think.
Oct 29 2018
The same *cannot* be said for a subkey that is marked specifically for certification or signing, and not for decryption.
Oct 27 2018
Aug 29 2018
I'm sorry but the explanation you give does not address the original issue I described, and which dkg then clarified. The discussion about AE is tangentially related, but the issue I described relates to the gpg interface:
Feb 1 2018
Sorry, I don't understand. Can you describe your use case in more detail?
Jan 31 2018
a key that is signed as its own subkey, in a construct where the key and subkey have the same fingerprint? what ever could be a valid use case for such a scenario?
uploaded the offending key for reference:
Nov 7 2017
Well, I gues it's complex enough to warrant strategic discussion, which can be done in this ticket :)
Jul 19 2017
Hm. Could you elaborate on that? Why do you think it's dangerous?
Isn't it much nicer if we semantically convey that a key doesn't have associated user id information, compared to just listing such keys between "Andre" and "Arnold"? I'd much rather special case the empty string in the key list than an arbitrary string that may or may not have a universally obvious meaning.
I think "anonymous" user ids are a valid use case, since openpgp doesn't allow "no" user ids. Disallowing zero-length user ids will just cause implementations that intend to use anonymous user ids to use another type of "empty", like a single space character. And the effect of that will be that it's no longer trivially defined what an "anonymous" user id is for special handling, e.g. showing a localized "anonymous key" placeholder. Please don't restrict zero-length user ids.
Jul 13 2017
Well, yes, it's not general authentication like AE provides, didn't think this through entirely. However, handing encrypted data to gnupg and then not being sure if it was actually decrypted with a passphrase makes even the confidentiality property questionable.
Jun 23 2017
seems this was fixed along the way, then. I only tested with 2.1.18.
Jun 17 2017
here's a public key version of the same key. it was available easier and should reproduce the bug just as well
Jun 13 2017
user ids with length 0 do conform with rfc4880, though
The key was created programmatically by my standard approach, which is bastardizing openkeychain unit tests. good question about the passphrase - I don't remember exactly, but I'm guessing it's either empty or "x". doesn't really matter in the context of this particular bug I guess :)
Jun 12 2017
-----BEGIN PGP PRIVATE KEY BLOCK-----