sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher)


From: Casey Marshall
Subject: Re: [Keyserver] Hockeypuck 2.1.0 released (Andrew Gallagher)
Date: Thu, 10 Dec 2020 23:11:10 -0600

Date: Thu, 10 Dec 2020 19:59:46 +0000
From: Andrew Gallagher <andrewg@andrewg.com>
To: SKS Development and Deployment discussion <sks-devel@nongnu.org>,
        GnuPG Users <gnupg-users@gnupg.org>
Subject: Re: [Keyserver] Hockeypuck 2.1.0 released
Message-ID: <de8589f0-adb4-6cab-f909-2528bc33d4cc@andrewg.com" target="_blank">de8589f0-adb4-6cab-f909-2528bc33d4cc@andrewg.com>
Content-Type: text/plain; charset="utf-8"; Format="flowed"
How do you handle the gradual degradation of sync as different operators
implement divergent blacklists?

This might be a controversial opinion, but I would allow it to happen.

Even if reconciliation cannot provide perfect consistency in such a world, it is still useful as a gossip protocol to distribute new keys and signatures.

My prediction (given keyserver operator buy-in) is, some cohorts of like-minded keyserver operators will coordinate on their settings. Peers in these cohorts will keep relatively more closely in sync and propagate key material faster amongst themselves, than with those that have different policies that cause them to diverge more widely. Peers across these more divergent cohorts may still peer at a lower frequency, so key material accepted by both may still propagate.

-Casey

A
On 10/12/2020 17:07, Casey Marshall wrote:
> I've released Hockeypuck 2.1.0
> <https://github.com/hockeypuck/hockeypuck/releases/tag/2.1.0> [0], which


reply via email to

[Prev in Thread] Current Thread [Next in Thread]