> On Oct 15, 2020, at 17:58, Ángel <an...@pgp.16bits.net> wrote: > > First of all, those patches protect against a single poison key, > 0xE41ED3A107A7DBC7. By skipping the merge of changes to it, I think.
I suppose one is better than none. I also block several other (popular?) keys that are problematic at the NGINX level after having issues with them in the past causing server instability. It’s far from a perfect system, but between that and automatic service restarts when SKS crashes I rarely have to touch anything anymore. *knocks on wood* > Second, this may actually not be a good idea at all. sks key > reconciliation works by having two servers with different contents for > a "file" end up with the same one. If one of the parties is picky and > reject some keys the other has, the system might fall apart. > Ideally, a rejection of certain keys would have to be network-wide. > Otherwise, the reconciliation could fail, or the servers might be > continuously retrying that key which is actually rejected by the other > party. I'm not sure if this is actually a problem with this patch (I > hope someone better understanding the protocol can chime in and > explain), but seems a reason for concern. > Also, I expect that if you started from a dump which already has the > forbidden key, this patch was probably a no-op and that reconciliation > issue would go unnoticed. Meh. I understand your thought process here, but don’t see it as a problem. At worst, servers will keep thinking they need to recon a problem key with a remote server that will never accept it. I cannot foresee how this would cause any real strain on the network no less to the point it might fall apart … any more so than it is already at risk of anyway. -T > Best regards > >
signature.asc
Description: Message signed with OpenPGP
