On 2018-05-05 at 10:27 +0100, Andrew Gallagher wrote: > Sorry for the double. We don’t need to modify the protocol to enable > such checks. Whenever a server tries to recon with us, we can perform > a callback against its status page and run whatever sanity tests we > want before deciding whether to allow recon to proceed. This could be > rolled out without any need for coordination.
You'll need to ensure that initial_stat defaults to true and so forth then, since by default keyservers don't calculate the stats at startup, so such a keyserver won't be able to start peering for up to a day (3am by default). It's probably reasonable to change the default, but you'll want to make this explicit when you draw up your full workflow. Note though that the status pages are intended for humans and SKS the keyserver can speak SKS and reconcile with other codebases, such as Hockeypuck, which uses a different output format. You'll probably want to look into standardizing on something like a JSON output format, with fallback to heuristic matching upon the output formats used by the two current codebases. But still my point stands: the moment you change to defaulting to recon-open-to-everyone the scope of what counts as a security vulnerability changes, and being open to anyone causing unbounded computation will be a DoS security vulnerability. With enough other issues being tackled, I nudge once more to reconsider such a change. -Phil _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel