Re: Building SKS on Alpine Linux 3.12 with ocaml 4.08

[Todd Fleisher]

> On Oct 15, 2020, at 17:58, Ángel <angel@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