It is highly likely that this is the work of a troll.
The RSA subkey that was factored has an invalid self-signature in hpa's public key[1], which means that it wasn't really hpa who added the subkey. Since the sks-keyserver pool doesn't verify signatures[2], anyone could have inserted that subkey. So anyone could have purposefully picked an exploitable RSA subkey, added a fake signature to it, and uploaded it to the sks-keyserver pool.
Luckily, GPG will drop the subkey when retrieving hpa's public key since it doesn't have a valid self-signature. But for anyone scanning all the public keys without verifying signatures (for research, etc.), this key might get recognized and cause a shitstorm. Which is exactly what has happened.
So far, there's no evidence that there is a conspiracy to weaken RSA keys. There is only evidence that someone inserted a bogus subkey into hpa's public key. There will be evidence of a conspiracy if we find a weak RSA key in the strongset that has a valid self-signature.
The RSA subkey that was factored has an invalid self-signature in hpa's public key[1], which means that it wasn't really hpa who added the subkey. Since the sks-keyserver pool doesn't verify signatures[2], anyone could have inserted that subkey. So anyone could have purposefully picked an exploitable RSA subkey, added a fake signature to it, and uploaded it to the sks-keyserver pool.
Luckily, GPG will drop the subkey when retrieving hpa's public key since it doesn't have a valid self-signature. But for anyone scanning all the public keys without verifying signatures (for research, etc.), this key might get recognized and cause a shitstorm. Which is exactly what has happened.
So far, there's no evidence that there is a conspiracy to weaken RSA keys. There is only evidence that someone inserted a bogus subkey into hpa's public key. There will be evidence of a conspiracy if we find a weak RSA key in the strongset that has a valid self-signature.
[1]: https://gist.github.com/anonymous/ba23ca66d2ca249e6f84#file-...
[2]: https://lists.gnupg.org/pipermail/gnupg-devel/2015-March/029...