https://gist.github.com/rjhansen/f716c3 ... 96e54e4b7e
I don't think you need to read the whole horrible story and the questionable moaning about this very foreseeable attack if you are not a frequent keyserver user. This is the main part:
Mitigation no. 1 is easy if I understood correctly, everybody should remove keyserver entries from their systems as quick as possible.. But where would be the second dirmngr.conf on our system and what happens without it?Any certificate may be poisoned at any time, and is unlikely to be discovered until it breaks an OpenPGP installation.
The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor's public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver network the vendor's now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. Even downloading the vendor's certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network.
At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately.
Users who are confident editing their GnuPG configuration files should follow the following process:
(1) Open gpg.conf in a text editor. Ensure there is no line starting with keyserver. If there is, remove it.
(2) Open dirmngr.conf in a text editor. Add the line keyserver hkps://keys.openpgp.org to the end of it.
keys.openpgp.org is a new experimental keyserver which is not part of the keyserver network and has some features which make it resistant to this sort of attack. It is not a drop-in replacement: it has some limitations (for instance, its search functionality is sharply constrained). However, once you make this change you will be able to run gpg --refresh-keys with confidence.
Also be very careful when importing keys from other repositories. Check key size before importing them. Also remember that pip, npm, pear, composer, ... use keys as well.
This might get bad really quickly if someone else with more malicious intent picks this up.