On 2014-04-28 at 13:32 -0400, Jeremy T. Bouse wrote: > I don't know about the others on the list but my configuration follows > the recommendations from > https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering which has > never stated anything about this issue as long as I've been following > it. Do we need to make changes to the documentation that's already out > there?
Speaking as the primary author of that page: It's a wiki page. It is updated as and when we discover new operational issues which affect peering; one of the pieces of advice was also updated with something which affected general usability, despite not being a peering issue, because it's the closest thing we've got to an operational best practices document to cover known issues to beware of. It did affect "whether or not the keyserver is fit to be included in pool definitions", as does this new discovery. Bitbucket's wiki controls mean that anyone can edit the page; the docs note that a bitbucket account isn't even needed. > As to the key you selected to test with it's no surprising it's a large > upload given that it's weasel's old 1024D Debian key with over 3K > signatures and one of the strong set keys as he stays high in the WoT. > His new 4096R key (62AF4031C82E0039) already have over 1K signatures on > it. In that case where do we set a sane upper bound as it will only > continue to grow on keys that make it into the strong set with thousands > of signatures? There are a couple of issues here. The most severe is that _any_ limit means that someone malicious can block upload of updates of any key they like, simply by adding a large number of signatures to the key. Further, appropriate attribution data might be used to turn this into a steganographic storage pool, provided for free by keyserver operators, so we don't want to make it unlimited. For now, if it's taken 15 years for someone keen on key signings to reach a 1MB limit, then I think that 8MB, covering 120 years of activity at such a rate, is likely to be enough for most normal mortal human beings. It's certainly enough to set as a limit for now, while we hem and haw over whether or not we need to extend HKP to support partial upload concepts and whether we've finally reached the point where there's enough impetus for distributed key blacklists that someone volunteers code for a workable proposal which keyserver operators are willing to use. -Phil
pgpp7InjP9TND.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/sks-devel
