On May 27, 2012, at 8:17 PM, John Marshall wrote: > On 27/05/2012 22:39, Jeffrey Johnson wrote: >> On May 27, 2012, at 6:15 AM, Robert J. Hansen wrote: >>> >>> "We never, never, never lose certificates." >> >> And what is being discussed is filtering an expired signature, not >> a public key, for one specific robo-signer. >> >> Even if the filtering was solely limited to >> an "opt-in" user requested hkp:// extension narrowly limited to just >> 0xca57ad7c >> expired signatures >> there starts to be a benefit to GPG users who otherwise are "cleaning" >> imported signatures manually. > > Users cleaning imported signatures *manually*? GnuPG users, at least, > can simply add the import-clean import-option to their gpg.conf. > > What warrant do we have for applying any filtering at the servers at > all? If the "problem" is one robo-signer, wouldn't it make sense to talk > to its minders? >
Would make sense, but the drip, drip, drip robo-signing has been going on for 7+ years. I originally thought 0xca57ad7c was a historical "mistake" that had to be lived with. Bu it seems that the same problem continues currently. It would _NOT_ be hard or necessarily controversial to filter the expired robo-signatures on retrieval through hkp:// … whether the gossip protocol can be changed to accommodate "filtering" is a far harder implementation, both because of "policy" as well as implementation. Adding a filter on retrieval shouldn't be too hard (imho). But if robo-signing with weekly, per-retrieval, re-signings and expiries its still active .. well its time (imho) to consider the consequences: do the math. Google 0xc5a7ad7c: to see the context: its not hard to find/see the issue. hth 73 de Jeff _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel
