[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] SKS apocalypse mitigation
From: |
Daniel Kahn Gillmor |
Subject: |
Re: [Sks-devel] SKS apocalypse mitigation |
Date: |
Fri, 23 Mar 2018 14:02:45 +0000 |
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] SKS apocalypse mitigation, Andrew Gallagher, 2018/03/23
- Re: [Sks-devel] SKS apocalypse mitigation, Yaron Minsky, 2018/03/23
- Re: [Sks-devel] SKS apocalypse mitigation, Andrew Gallagher, 2018/03/23
- Re: [Sks-devel] SKS apocalypse mitigation,
Daniel Kahn Gillmor <=
- Re: [Sks-devel] SKS apocalypse mitigation, Kristian Fiskerstrand, 2018/03/24
- Re: [Sks-devel] SKS apocalypse mitigation, Phil Pennock, 2018/03/24
- Re: [Sks-devel] SKS apocalypse mitigation, Andrew Gallagher, 2018/03/25
- Re: [Sks-devel] SKS apocalypse mitigation, brent s., 2018/03/25
- Message not available
- Message not available
- Message not available
- Message not available
- Re: [Sks-devel] SKS apocalypse mitigation, Michael Jones, 2018/03/25
- Re: [Sks-devel] SKS apocalypse mitigation, Hendrik Visage, 2018/03/26
Re: [Sks-devel] SKS apocalypse mitigation, Alin Anton, 2018/03/24