Re: [Sks-devel] Peering Issues - High IO ending with Eventloop.SigAlarm always occur with 1 peer

[Kim Minh Kaplan]

Moritz Wirth wrote:
>
> Hi,
>
> this issue already known for several months now - see [0], [1].
>
> The keys used for this are very large (around 30-60MB). Syncing them takes 
> some bandwith and indexing/writing them to the disk consumes a lot of CPU and 
> I/O resources. If the addition to the database fails, the key is added again 
> when another peer synchronizes it, causing the same load (which results in 
> the large I/O spikes that you see).
>
> SKS is single threaded and therefore, any other action is blocked while the 
> key addition takes place. This is also known for years and the fact that it 
> can be easily used for attacks is ignored.
>
> If I remember correctly, the behaviour above is intended and therefore, I 
> would not expect any fixes in the next months. There have been some fixes 
> which exclude some of the bad keys [2] (which might be included in the 
> ubuntu/debian sks packages so this may be why it stopped over the last 
> months), however this only works as long as nobody generates and uploads a 
> new key.
>
> Best Regards,
>
> Moritz
>
> [0]: 
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/61/key-addition-failed-blocks-web-interface
> [1]: 
> https://bitbucket.org/skskeyserver/sks-keyserver/issues/60/denial-of-service-via-large-uid-packets
> [2]: https://lists.nongnu.org/archive/html/sks-devel/2018-07/msg00053.html

Another solution is to tune settings so that the key is downloaded and saved.

https://lists.nongnu.org/archive/html/sks-devel/2018-06/msg00072.html