On Sun, 30 Jun 2019 at 00:36:19 -0700, Mirimir via Gnupg-users wrote: > | High-risk users should stop using the keyserver network immediately. > > So OK, 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.
Third-party signatures from locally unknown certificates are arguably not so useful, so how about using ‘--keyserver-options import-clean’? (Or even making it the default behavior?) Of course it's not perfect as it still clutters network traffic and gpg(1) needs to clean up the mess client-side (which is slow and CPU expensive), but at least it mitigates the DoS attack: it doesn't prevent keyring updates, and limits the bloat on disk. Compare ~$ export GNUPGHOME="$(mktemp --tmpdir=/dev/shm --directory)" ~$ alias time="command time -f '%E (%U user, %S sys) %P CPU %Mk maxres'" ~$ gpg --import /usr/share/keyrings/*.gpg ~$ gpg --with-colons --list-sigs | grep -c ^pub: 1187 ~$ gpg --with-colons --list-sigs | grep -c ^sig: 56001 ~$ stat -c %s "$GNUPGHOME/pubring.kbx" 34041308 ~$ time gpg --recv-keys \ C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \ CC11BE7CBBED77B120F37B011DCBDC01B44427C7 gpg: key 1DCBDC01B44427C7: 149109 signatures not checked due to missing keys gpg: error writing keyring '…/pubring.kbx': Provided object is too large gpg: key F20691179038E5C6: 54608 signatures not checked due to missing keys gpg: error writing keyring '…/pubring.kbx': Provided object is too large […] Command exited with non-zero status 2 10:53.44 (269.47 user, 362.81 sys) 96% CPU 330976k maxres (which fails the keyring update operation) with […] ~$ time gpg --keyserver-options import-clean --recv-keys \ C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 \ CC11BE7CBBED77B120F37B011DCBDC01B44427C7 gpg: key 1DCBDC01B44427C7: 1 duplicate signature removed gpg: key 1DCBDC01B44427C7: 1 signature reordered gpg: key 1DCBDC01B44427C7: public key "Robert J. Hansen <r...@sixdemonbag.org>" imported gpg: key F20691179038E5C6: 2 duplicate signatures removed gpg: key F20691179038E5C6: 2 signatures reordered gpg: key F20691179038E5C6: "Daniel Kahn Gillmor <d...@fifthhorseman.net>" not changed gpg: no ultimately trusted keys found gpg: Total number processed: 2 gpg: imported: 1 gpg: unchanged: 1 49:48.80 (1668.47 user, 1305.03 sys) 99% CPU 190840k maxres (The initial import of /usr/share/keyrings/*.gpg is merely there to start with a non-trivial keyring. In particular, a keyring containing certificates that issued third-party signatures on 1DCBDC01B44427C7 and F20691179038E5C6. The keyring even contains a non-poisoned version of dkg's key, as on my system the glob matches ‘/usr/share/keyrings/debian-keyring.gpg’.) I suppose validating keyservers are the way to go, but it seems like there is currently no good solution for third-party signatures. For workflow relying on these (at least for locally known signers), or which for some other reason need to stick to SKS, a possible mitigation is to pass `--keyserver-options import-clean`. As seen above refreshing the keyring might take a veeery long time (possibly room for improvement, from an algorithmic perspective I don't get why filtering signature packets from unknown signers is so slow), but at least succeeds in getting updates from SKS. -- Guilhem.
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users