... ... https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f Also: https://gist.github.com/rjhansen/f716c3ff4a7068b50f2d8896e54e4b7e I wonder how bad this could get. I can purge requests to SKS keyservers from my machines, but what about upstream impacts? As I understand it, GnuPG authentication is pervasive. And I suspect that getting missing keys from SKS is common. As an error trap, if nothing else. Someone might, for example, poison numerous Debian package keys. What would that break?
Might be difficult but can I get a very basic explanation of this. Preferably something just above poison certificate = SOL. Thanks.
It's really pretty simple. The SKS keyserver network is pretty stressed, so responses are typically slow. When you're checking a key with a few signatures, that's not too much of a problem. But if the key has 1500 signatures, you get into a cycle of timeouts and restarts. If you don't check signatures, you'll probably be OK. But that's quite the limitation.
Yes. They're in ISOs, and updated via signed packages. I also get that kernel devs are safe. And many/most package devs. So I'm not freaking out as much. But there is this at https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062141.html
Public Certificate Poisoning Can Break Some OpenPGP Implementations July 2, 2019 https://www.bleepingcomputer.com/ne...oning-can-break-some-openpgp-implementations/
I've done some testing in a fresh VM. And it doesn't seem so bad. I installed Thunderbird, Enigmail and dirmngr in a Debian 9.5 x64 VM with Gnome. Using Enigmail Key Management, I tried to get rjh's 1DCBDC01B44427C7 from hkps.pool.sks-keyservers.net, but that just timed out. So I downloaded it from SKS keyservers via HTTPS. And it was ~60MB When I tried importing from the downloaded file, it just sat there at 100% CPU. So I got it from https://keybase.io/rjh and imported from clipboard in Enigmail Key Management. That worked just fine. Then I refreshed keys in Enigmail, leaving hkps.pool.sks-keyservers.net as the default keyserver. And that failed, within a minute, with the error: | Downloading of keys failed | gpg: keyserver receive failed: No data Then I deleted rjh's key, and got my own from Keybase, and imported it. And my key refreshed in seconds, using hkps.pool.sks-keyservers.net, with no errors. So I impored rjh's key again, and tried refreshing keys in Enigmail. But it failed, with the same error that I got with rjh's key by itself: | Downloading of keys failed | gpg: keyserver receive failed: No data Then I tried in terminal, and found that my key refreshed, but rjh's key did not: | user@debian:~$ gpg --refresh-keys | gpg: refreshing 2 keys from hkps://hkps.pool.sks-keyservers.net | gpg: key ...: 22 signatures not checked due to missing keys | gpg: key ...: "mirimir <mirimir@riseup.net>" not changed | gpg: Total number processed: 1 | gpg: unchanged: 1 Then I disabled rjh's key, and found that my key now refreshed quickly in Enigmail. Still using hkps.pool.sks-keyservers.net. So that's good news, I think. Trying to import rjh's key from hkps.pool.sks-keyservers.net did hang, but I could easily kill the attempt. After I got his key from Keybase, trying to refresh it from hkps.pool.sks-keyservers.net failed, but it failed quickly. But neither test apparently broke anything.
