[I previously responded to a specific message not related to this thread but none the less... ]
On 03/23/2018 03:02 PM, Daniel Kahn Gillmor wrote: > 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. I would definitely agree with this > >> 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 agree with this as well, UAT generally have very limited value, so if we introduce a filter to skip all UATs I'm all fine with making that a requirement across severs in sks-keyservers.net pools. That isn't something that restricts servers overall, but anyhow... > 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. and here comes at least one of the issues, we're talking about a filter that responds to a specific alteration; mainly we need to specify a specific filter for a specific version and move from there, which can be relatively easy given sufficient time. > > --dkg > > [0] see for example > https://bitbucket.org/skskeyserver/sks-keyserver/pull-request/20/trim-local-certifications-from-any-handled > > > > _______________________________________________ > Sks-devel mailing list > Sks-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/sks-devel > -- ---------------------------- Kristian Fiskerstrand Blog: https://blog.sumptuouscapital.com Twitter: @krifisk ---------------------------- Public OpenPGP keyblock at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 ---------------------------- "There is no urge so great as for one man to edit another man's work." (Mark Twain)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel