Change Details

My OpenPGP certificate `0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6` was flooded with spam on or about June 18 2019. The version of it on the SKS keyserver network is now ~17MiB. gpg chokes on it: ``` 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ gpg --homedir=$(pwd) --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 gpg: keybox '/tmp/cdtemp.7QJ3xD/pubring.kbx' created gpg: key F20691179038E5C6: 4 duplicate signatures removed gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys gpg: key F20691179038E5C6: 4 signatures reordered gpg: error writing keyring '/tmp/cdtemp.7QJ3xD/pubring.kbx': Provided object is too large gpg: key F20691179038E5C6: public key "[User ID not found]" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: not imported: 1 2 dkg@alice:/tmp/cdtemp.7QJ3xD$ ``` But, if i force gpg into using an old-style keyring instead of a keybox, it does import: ``` 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ rm -f pubring.kbx* 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ touch pubring.gpg 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ gpg --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 gpg: key F20691179038E5C6: 4 duplicate signatures removed gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys gpg: key F20691179038E5C6: 4 signatures reordered gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ ``` Note that i'm not suggesting that it would be *good* for gpg to do this import. In fact, i think the import limit could maybe even be reduced. Once the flooded certificate is imported, it incurs a huge performance penalty for even the most basic tasks in GnuPG (which i'll document in a separate ticket), so it is actively bad to have such a thing in your local keyring. Using keybox again, I also tried to receive that key using `--import-options import-clean`, and `--import-options import-minimal`. In neither case was any certificate merged. This suggests that (for example): * a certificate revocation will not be merged * expiration updates will not be merged * new subkeys will not be merged Here's what i think *should* happen, if we want gpg to be able to safely refresh keys from the keyservers: * if the certificate overall is too large to import, gpg should preferentially drop all packets that would have been dropped had the certificate been "cleaned" (as though `--import-options import-clean` were present, and functional) * If the cleaned certificate is still larger than the importable size, gpg should drop all the packets that would have been dropped had it been minimized. (as though `--import-options import-minimal` were present, and functional). * if the minimized certificate is still too large to merge, then the primary key packet and the earliest "hard" revocation direct key signature should be merged.

My OpenPGP certificate `0xC4BC2DDB38CCE96485EBE9C2F20691179038E5C6` was flooded with spam on or about June 18 2019. The version of it on the SKS keyserver network is now ~17MiB. gpg chokes on it: ``` 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ gpg --homedir=$(pwd) --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 gpg: keybox '/tmp/cdtemp.7QJ3xD/pubring.kbx' created gpg: key F20691179038E5C6: 4 duplicate signatures removed gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys gpg: key F20691179038E5C6: 4 signatures reordered gpg: error writing keyring '/tmp/cdtemp.7QJ3xD/pubring.kbx': Provided object is too large gpg: key F20691179038E5C6: public key "[User ID not found]" imported gpg: Total number processed: 1 gpg: imported: 1 gpg: not imported: 1 2 dkg@alice:/tmp/cdtemp.7QJ3xD$ ``` But, if i force gpg into using an old-style keyring instead of a keybox, it does import: ``` 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ rm -f pubring.kbx* 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ touch pubring.gpg 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ gpg --homedir=$(pwd) --recv C4BC2DDB38CCE96485EBE9C2F20691179038E5C6 gpg: key F20691179038E5C6: 4 duplicate signatures removed gpg: key F20691179038E5C6: 54614 signatures not checked due to missing keys gpg: key F20691179038E5C6: 4 signatures reordered gpg: key F20691179038E5C6: public key "Daniel Kahn Gillmor <dkg@fifthhorseman.net>" imported gpg: no ultimately trusted keys found gpg: Total number processed: 1 gpg: imported: 1 0 dkg@alice:/tmp/cdtemp.7QJ3xD$ ``` Note that i'm not suggesting that it would be *good* for gpg to do this import. In fact, i think the import limit could maybe even be reduced. Once the flooded certificate is imported, it incurs a huge performance penalty for even the most basic tasks in GnuPG (which i'll document in a separate ticket), so it is actively bad to have such a thing in your local keyring. Using keybox again, I also tried to receive that key using `--import-options import-clean`, and `--import-options import-minimal`. In neither case was any certificate merged. This suggests that (for example): * a certificate revocation will not be merged * expiration updates will not be merged * new subkeys will not be merged Here's what i think *should* happen, if we want gpg to be able to safely refresh keys from the keyservers: * if the certificate overall is too large to import, gpg should preferentially drop all packets that would have been dropped had the certificate been "cleaned" (as though `--import-options import-clean` were present, and functional) * If the cleaned certificate is still larger than the importable size, gpg should drop all the packets that would have been dropped had it been minimized. (as though `--import-options import-minimal` were present, and functional). * if the minimized certificate is still too large to merge, then the primary key packet and the earliest "hard" revocation direct key signature should be merged.