[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] SKS apocalypse mitigation
From: |
Kristian Fiskerstrand |
Subject: |
Re: [Sks-devel] SKS apocalypse mitigation |
Date: |
Sat, 24 Mar 2018 19:01:40 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 |
[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
> address@hidden
> 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] 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, 2018/03/23
- Re: [Sks-devel] SKS apocalypse mitigation,
Kristian Fiskerstrand <=
- 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