On Fri 2018-03-23 11:10:49 +0000, Andrew Gallagher wrote: > Updating the sets on each side is outside the scope of the recon > algorithm, and in SKS it proceeds by a sequence of client pull requests > to the remote server. This is important, because it opens a way to > implement object blacklists in a minimally-disruptive manner.
as both an sks server operator, and as a user of the pool, i do not want sks server operators to be in the position of managing a blacklist of specific data. > The trick is to ensure that all the servers in the pool agree (to a > reasonable level) on the blacklist. This could be as simple as a file > hosted at a well known URL that each pool server downloads on a > schedule. The problem then becomes a procedural one - who hosts this, > who decides what goes in it, and what are the criteria? This is a really sticky question, and i don't believe we have a global consensus on how this should be done. I don't think this approach is feasible. > Another effective method that does not require an ongoing management > process would be to blacklist all image IDs - this would also have many > other benefits (I say this as someone who once foolishly added an > enormous image to his key). This would cause a cliff edge in the number > of objects and, unless carefully choreographed, could result in a mass > failure of recon. > > One way to prevent this would be to add the blacklist of images in the > code itself during a version bump, but only enable the filter at some > timestamp well in the future - then a few days before the deadline, > increase the version criterion for the pool. That way, all pool members > will move in lockstep and recon interruptions should be temporary and > limited to clock skew. I have no problems with blacklisting User Attribute packets from sks, and i like Andrew's suggestion of an implementation roll-out, followed by a "switch on" date for the filter. I support this proposal. I've had no luck getting new filters added to sks in the past [0], so i'd appreciate if someone who *does* have the skills/time/commit access could propose a patch for this. I'd be happy to test it. --dkg [0] see for example https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20/trim-local-certifications-from-any-handled
signature.asc
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel