The underlying recon algorithm can be stopped at any time and only the discovered differences can be processed. In other words, it should be possible to put an explicit timeout on recon time - you will get a partial synchronization, but that might be good enough as long as you reconcile at a faster rate than the average number of differences.
> On May 5, 2018, at 4:03 AM, Phil Pennock <sks-devel-p...@spodhuis.org> wrote: > > On 2018-05-05 at 08:53 +0100, Andrew Gallagher wrote: >>> On 5 May 2018, at 08:48, Phil Pennock <sks-devel-p...@spodhuis.org> wrote: >>> If you peer with someone with no keys >>> loaded, it will render your server nearly inoperable. >> >> I was aware that recon would fail in this case but not that the failure mode >> would be so catastrophic. Is there no test for key difference before recon >> is attempted? > > It's the calculation of the key difference which is the problem. That's > what recon is. > > Recon figures out the difference in the keys present. It's highly > efficient for reasonable deltas in key counts. Yaron Minskey wrote > papers on the topic, leading to his academic degree; they're linked > from: > https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Home > > After recon figures out what the local server needs, it then requests > those keys using HKP. > > While you could modify the protocol to do something like announce a > key-count first, that's still only protection against accidental > misconfiguration: worthwhile and a nice-to-have if there's ever an > incompatible protocol upgrade anyway, to have a safety auto-cutoff to > back up the manual checks people do, but not protection against malice. > > Fundamentally, reconciliation between datasets requires computation. > You can add safety cut-offs, and rate-limits per IP and CPU limits per > request and various other things, but none of those help if you're > trying to protect the keyservers from a half of the apocalypse > scenarios. > > -Phil > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel --- Prof. Ari Trachtenberg ECE, Boston University trach...@bu.edu http://people.bu.edu/trachten
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
