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. 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? -- Andrew Gallagher
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel