No, the SKS keyserver system cannot be fixed. So we need Best Practice advice from Tor Project on a safe way to obain signing keys as needed to verify the latest Tor Browser tarball, the latest Tails ISO image, etc.

GPG people describe this attack as "devastating". Daniel Kahn Gillmor says he thought about leaving the software world.

From R.J. Hansen, the maintainer of the GPG FAQ, whose personal key was poisoned in last week of June:

https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f

> In the last week of June 2019 unknown actors deployed a certificate spamming attack against two high-profile contributors in the OpenPGP community (Robert J. Hansen and Daniel Kahn Gillmor, better known in the community as "rjh" and "dkg"). This attack exploited a defect in the OpenPGP protocol itself in order to "poison" rjh and dkg's OpenPGP certificates. Anyone who attempts to import a poisoned certificate into a vulnerable OpenPGP installation will very likely break their installation in hard-to-debug ways. Poisoned certificates are already on the SKS keyserver network. There is no reason to believe the attacker will stop at just poisoning two certificates. Further, given the ease of the attack and the highly publicized success of the attack, it is prudent to believe other certificates will soon be poisoned.
>
> This attack cannot be mitigated by the SKS keyserver network in any reasonable time period. It is unlikely to be mitigated by the OpenPGP Working Group in any reasonable time period. Future releases of OpenPGP software will likely have some sort of mitigation, but there is no time frame. The best mitigation that can be applied at present is simple: stop retrieving data from the SKS keyserver network.

> ...

> 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.

Tor, Tails, Debian Project should all issue immediate warnings to users to prevent users who have not heard about the issue (e.g newbies, the very people Tor Project needs to attract to survive) from naively trying to download the signing keys from an SKS keyserver and immediately breaking their GPG keyring in ways which will be hard to fix, and are likely to cause newbies to stop using Tor and to be very annoyed with Tor Project (not understanding that this problem was not caused by TP and is well beyond TP's ability to fix).

It seems that Debian Project has NOT yet issued a security patch for GPG incorporating the latest code from Werner Koch which should at least prevent a GPG keyring from being rendered unusable from an autoupdate from an SKS keyserver. Making matters worse, the rollover to the new Debian stable (Buster, a now ironic nickname) occured in the same time frame as the keyspamming attacks. (AFAIK the debian keyring deb available at the Debian repos is not poisoned, but hope others will help me check.)

It seems that some experimental keyservers which only serve the self-signed parts of signatures added to a key are available (but I fear may crash under sudden high demand); Hansen mentions one in his post.

Before the next Tor Browser version and the next Tails edition are issued, users must be informed of how they can use GPG to verify the integrity of the code (sort of) without poisoning their GPG keyrings. It is not enough to say "never again import a key you obtained from an SKS server because we will need to obtain new signing subkeys etc. somehow somewhere.

So far we know that the personal keys of RJH and DKG were poisoned, as was the Tor Browser developers signing key. We must anticipate that all security-critical and widely used GPG signing keys will soon be poisoned in the SKS keyservers. It follows that users will need some other way to obtain the signing keys to verify new versions of things we need such as the latest Tor Browser.

Who is responsible? Too early to speculate very far, but the attack appears timed to cause maximal damage because of Debian stable rollover. We know that it coincides with the Russian government adopting a version of Debian as the official OS for government use. That is vaguely suggestive, but only vaguely so.