On 2012-08-01 at 00:44 -0400, David Shaw wrote: > Possibly a best of both worlds would be to have SKS do its cleaning, and then > GPG, after it gained the ability to do a repair, would start requesting keys > with "clean=off". This way, clients that could not repair would not get > mangled keys, and clients that could repair would get the whole key and be > able to repair it.
While "clean" has the advantage of being out there, this scheme means that if there's a later problem that needs to be cleaned up, gpg will continue to ignore the clean-up. What about a "noclean" option which takes a comma-separated list, or can be given multiple times, of keywords for clean features that should be skipped? We then just need a concise name for the current cleaning feature. Since ~nobody is using clean programmatically now, and sks goes through occasional forcing functions to get the network updated (for at least the keyservers which GnuPG users are likely to care about), this should work? While technically a registry would be helpful, we can avoid that bureaucracy by just declaring sks the de-facto definition of tags until such time as someone has a second clean implementation and wants to add their own, and just have everyone informally "do the sane thing" and agree on values. (This also establishes use of the feature, rather than being pie-in-the-sky, which is helpful if a later re-attempt at standardising HKP wants to list the registry for IANA maintenance). -Phil _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel