On 2013-09-12 at 19:40 -0400, Daniel Kahn Gillmor wrote: > While this seems like it is probably a fixable bug for someone who knows > their way around the codebase, I forsee problems with synchronizing the > pool, if some SKS keyservers start following the spec and others remain > non-compliant. > > Any thoughts or suggestions on how to resolve this problem?
A hack would be to have a filter on, which strips them by default, and clean=off disables that. The data's out there, trying to pretend it's not would be problematic in many ways, so we might as well just ensure that normal retrievals don't pick up the sigs, and also of course block _new_ uploads of such sigs. We're then left with some accumulated historical cruft which can be retrieved if cleaning is explicitly disabled, which clients won't do by default. Seems like a reasonable compromise to me. -Phil
pgpT8bFL8EhM5.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
