Re: [Sks-devel] Key updates not propagating

[Alain Wolf]

Hi Andrew

Am 18.01.19 um 13:05 schrieb Andrew Gallagher:
> Hi, all.
> 
> I extended the expiry on my key (0xfb73e21af1163937) over a week ago and
> uploaded it to the pool. I foolishly thought that doing so a few days in
> advance of its expiry would be sufficient. Not so. Even today, I see
> that many pool members still have not received my new self-sig.
> 
> This has caused much disruption on servers that have monkeysphere
> configured - logins are still failing at random depending on what pool
> server they connect to. Given that dirmngr is a persistent background
> process, the DNS round robin doesn't shuffle the pool as fast as you
> might think. Clients that hit a bad pool member keep hitting the same
> bad pool member until the dirmngr process is restarted. Today I had to
> kill dirmngr on one particular server *twice* before it found a good
> pool member.
> 
> I don't believe this non-propagation is simply a result of bad
> connectivity - I can see one "bad" pool member (sks1.cryptokeys.org.za)
> is connected directly to the "good" pool server (pgpkeys.urown.net) that
> I uploaded my self-sig to. sks1.cryptokeys.org.za has not been correctly
> gossiping with *any* of its peers for over a week, and yet remains in
> the pool.

While sks1.cryptokeys.org.za is listing pgpkeys.urown.net as peer. It
is not cross-peered back by pgpkeys.urown.net.

> 
> Also, to my surprise, one of the high-performance nodes (pgpkeys.hu) is
> a "bad" pool member that has not yet discovered my self-sig. I suspect
> this is because it is weakly connected to the rest of the pool, and
> intermittent gossip failures have left it semi-detached.
> 
> All this is an enormous red flashing light.
> 
> If the pool members are not mutually well-connected, then uploading a
> key (or more importantly, a revocation) to the pool is not a guarantee
> that a client that connects to the pool will receive that information in
> a timely manner. The basic assumption of a decentralised store of
> information is broken.
> 
> I have not been running a keyserver myself since the first poison-key
> incident. Given the ongoing poison-key problems I am unlikely now to
> ever run one again, unless the entire codebase is overhauled. I have
> neither the time, energy nor skillset to perform this task, and it is
> becoming clear that nobody else does either.
> 
> This is not anyone's fault. It is just an unfortunate reality that we
> have to accept. SKS is end-of-life.
> 
> WKD is a useful and simple tool for finding keys that match email
> addresses. We do not need the keyservers for this any more. What WKD
> does not provide is twofold:
> 
> 1. A way to search for keys that do not correspond to email addresses
> (e.g. code signing keys)
> 2. A way to refresh key validity (self-sigs and revocations)
> 
> I suggest that we start by solving these two narrow problems.
> 
> Might it be possible to replace the keyserver network with a lightweight
> URL redirection service? This would remove the requirement for the
> keyservers to host any data at all, solving multiple problems in one
> stroke. The main disadvantage would be that it would be simple to block
> timely distribution of revocations - but right now this isn't happening
> anyway.
> 
> Thoughts?
> 
> 

Regards

-- 
pgpkeys.urown.net 11370 # <address@hidden> 0x27A69FC9A1744242

signature.asc
Description: OpenPGP digital signature