On Sat, Sep 14, 2013 at 05:00:28PM -0400, Robert J. Hansen wrote: > On 9/14/2013 3:08 PM, Daniel Kahn Gillmor wrote:
> > If the keyserver network actively forwards these certifications, > > then users of the keyserver network and local certifications stand a > > greater risk of global data leakage that they do not want. Correct. I specifically use --lsign-key on keys I've carefully checked and keyrings I copy around in binary (and under revision control). Since GPG doesn't normally export non-exportable sigs: lsign Same as "sign" but the signature is marked as non- exportable and will therefore never be used by others. This may be used to make keys valid only in the local environment. but can be [mis]configured to send/receive them to/from keyservers with: --keyserver-options export-local-sigs import-local-sigs or, far more likely with: export-options export-local-sigs Allow exporting key signatures marked as "local". This is not generally useful unless a shared keyring scheme is being used. Defaults to no. import-options import-local-sigs Allow importing key signatures marked as "local". This is not generally useful unless a shared keyring scheme is being used. Defaults to no. permanently set in gpg.conf - for users who also employ lsign and manage their keyrings manually. Such users would ALWAYS UNWITTINGLY LEAK these signatures via manual copy/paste, which is still quite useful for publishing keys on webpages, for example. In fact, it seems that I still have: import-options import-unusable-sigs import-local-sigs export-options export-unusable-sigs export-local-sigs and even a very old repair-hkp-subkey-bug lurking in my gpg.conf. So, especially in light of my [mis]configuration, I would prefer that keyservers DO NOT leak what "will therefore never be used by others." > Please show me real users who are having troubles dealing with this bug. I have a current SKS keydump, but I don't know if pgpring (see older mutt tarballs) decodes/reports that flag. It seems that pgpdump 0.28, which does, can't fully process the files: %pgpdump sks-dump-0025.pgp | grep -c "Public Key Packet" pgpdump: unknown compress algorithm. 12360 (of ~15,000 keys each)... > Not just you, because we've already established you're in love with > weird corner cases. If this is affecting real users then I would be all > in favor of further discussion on this subject. Without them, though, > I'm inclined to say "enough already!" ...so, without data, we can't be sure if this is, indeed, one of those "weird corner cases." > decision is, then there is no wrong decision. Move forward and respect > the decision of the person making the call. In this case, whatever > decision the SKS maintainers make, I will cheerfully accept. > have arguments in their favor. Ultimately, it's up to the maintainers > and the keyserver community to decide which will be the canonical behavior. I, for one, do want to see this patch/bugfix in SKS as well as eventually reflected in the pool criteria. > Although I believe SKS's behavior as it currently stands is technically > in error, I do not believe the alternatives you are presenting amount to > a good fix. I encourage the maintainers and the community to not worry AIUI, the patch acknowledges that end users won't generally want, and therefore won't usually request, such extraneous/leaked data. At the same time, it doesn't fragment the SKS pool unnecessarily. If that isn't a win-win, I don't know what is. -- Jason Harris | PGP: This _is_ PGP-signed, isn't it? jhar...@widomaker.com _|_ Got photons? (TM), (C) 2004
pgptlOkdWYr6E.pgp
Description: PGP signature
_______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel