Mirimir via Gnupg-users <gnupg-users@gnupg.org> writes: >> - Embeds a hardcoded list of already-disrupted keys for which packets >> should be filtered-out when serving them > > That's what I meant. Plus some mechanism for testing keys, so poisoned > ones are blocked, as soon as possible. > > It'd also be useful for SKS to report "this key has been poisoned", and > suggest alternative sources, rather than just failing silently.
I think we can't rely on humans actually reading the output, even if GnuPG was able to display the output on eg. `--refresh-keys` in a way understandable by a human. Also, the aim of my suggestion was to actually *not* block the keys. This second point of part 1 is there to just filter some hardcoded list of packets, thus making key updates still propagate. The first point was there to prevent additional keys from being poisoned, and the second to limit the damage caused by already-existing keys -- the first one is unfortunately quite necessary, as sks-keyservers can't reasonably be coordinating changes on the ~220 keyservers every time a new key gets poisoned (or even twice, for that matter, one flag day is already bad enough) >> Do you think such a plan might be reasonably done, to at least keep the >> most basic functionality of not breaking existing installations and >> allow them to keep revocations flowing? The biggest issue I can see is >> it requires a quite big amount of development work. > > But less work than actually fixing SKS, right? Well, nowadays “fixing SKS” means “making hagrid able to synchronize its cryptographic-only content and propagate third-party signatures under some circumstances”, as far as I understand. _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
