SKS and GnuPG related issues and possible workarounds

Konstantin Boyandin lists at boyandin.info
Sat Jul 6 18:35:01 CEST 2019


Since the list archives can be read by anyone, it's obvious the possible 
wrongdoers are monitoring the list closely, and can take any and all 
suggestions into account, to adapt further goals.

Sincerely,

Konstantin Boyandin

Ryan McGinnis via Gnupg-users wrote 2019-07-06 18:50:
> Someone brought it to my attention that my key is now one of the
> affected keys; I think from this we can probably surmise that
> whoever(s) is doing this probably reads this list as this email
> address doesn’t see heavy circulation.
> 
> -Ryan McGinnis
> 
> https://bigstormpicture.com
> 
> PGP: 5C73 8727 EE58 786A 777C 4F1D B5AA 3FA3 486E D7AD
> 
> Sent with ProtonMail
> 
> On Sat, Jul 6, 2019 at 00:33, Teemu Likonen via Gnupg-users
> <gnupg-users at gnupg.org> wrote:
> 
>> Konstantin Boyandin via Gnupg-users [2019-07-05T20:45:59-04:00]
>> wrote:
>> 
>>> ATM, none of systems I use GnuPG in has been hit with the
>> signature
>>> flood disaster. If I might miss that point - is it possible to
>> get,
>>> somehow, the list of flooded keys IDs (if anyone keeps the stats)?
>> 
>> I don't maintain a list and such a list can be always outdated
>> anyway.
>> Better option is to set protective settings right now in gpg.conf
>> file.
>> 
>> keyserver-options import-clean
>> # maybe also:
>> import-options import-clean
>> 
>> With option "import-clean" key import operations accept only key
>> signatures from already known keys. With poisoned keys the import
>> operation can take time but at least your local keyring is protected
>> from importing them.
>> 
>> The gpg(1) manual page for version 2.1.18 (Debian) is misleading,
>> though.
>> 
>> import-clean
>> After import, compact (remove all signatures except the
>> self-signature) any user IDs from the new key that are
>> not usable. Then, remove any signatures from the new
>> key that are not usable. This includes signatures that
>> were issued by keys that are not present on the
>> keyring. This option is the same as running the --edit-
>> key command "clean" after import. Defaults to no.
>> 
>> It says "After import" but according to Werner Koch[1] it actually
>> strips unknown key signatures _before_ importing them to the local
>> keyring. The manual also says that "This option is the same as
>> running
>> the --edit-key command 'clean' after import." This is also wrong or
>> misleading because it may lead user thinking that in import
>> oprations
>> first all keys and key signatures are imported to local keyring and
>> then
>> they are cleaned.
>> 
>> -----
>> 1.
>> https://lists.gnupg.org/pipermail/gnupg-users/2019-July/062239.html
>> 
>> --
>> /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
>> // https://keys.openpgp.org/search?q=tlikonen@iki.fi
>> / https://keybase.io/tlikonen https://github.com/tlikonen



More information about the Gnupg-users mailing list