Re: [Sks-devel] Dumps/importing & de-peering (WAS: Re: SKS apocalypse mitigation)

[brent s.]

On 05/05/2018 10:22 AM, Andrew Gallagher wrote:
> 
>> On 5 May 2018, at 15:00, brent s. <address@hidden> wrote:
>>
>> (a) is taken care of by recon already (in a way),
> 
> According to a list message from earlier today it is not. If the delta is 
> small, recon proceeds. If it is large, it breaks catastrophically. There is 
> no (current) way to test nicely.
> 

sorry, should have clarified- i mean the "generating deltas" part of (a).

>> but the problem for
>> (b) is the "standard place" - SKS/recon/HKP/peering is, by nature,
>> unfederated/decentralized. sure, there's the SKS pool, but that
>> certainly isn't required for peering (even with keyservers that ARE in
>> the pool) nor running sks. how does one decide the "canonical" dump to
>> be downloaded in (b)?
> 
> There can be no canonical dump of course. Each peer can provide its own dump 
> at a well known local URL. This is even more important if and when we allow 
> divergent policy. 

hrm. i suppose, but i'm under the impression not many keyserver admins
run their own dumps? (which i don't fault them for; the current dump i
have in its uncompressed form is 11 GB (5054255 keys). granted, you
don't see new keyserver turnups often, but still -- that can be a
lengthy download, plus the fairly sizeable chunk of time it takes for
the initial import.)


-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

signature.asc
Description: OpenPGP digital signature