Using the "clean" function (and the "PGP Global Directory")

Doug Barton dougb at
Wed Jun 23 21:40:32 CEST 2010

On 06/22/10 20:44, Dan Mahoney, System Admin wrote:
> On Tue, 22 Jun 2010, David Shaw wrote:
>> On Jun 22, 2010, at 11:02 PM, Dan Mahoney, System Admin wrote:
>>> It seems there's two interesting problems which inter-relate.
>>> The first is PGP corporation's "global directory", which seems to
>>> operate orthogonally from every other keyserver I've seen.  It's
>>> HTTP-only, not queryable by any of the open-source clients (in fact,
>>> it doesn't support wildcard searches at all, and returns a captcha
>>> before delivering results), and not SUBMITTABLE to from any of the
>>> open source clients.
>> Not exactly.  The GD speaks LDAP, so you can set your keyserver to
>> ldap:// and you can query and submit, etc.
> Interesting, I didn't see mention of that.  I must try this (assuming
> I've built with LDAP support, that is, which under BSD is a bit obtuse).

Assuming you're talking about FreeBSD, 'ls
/usr/local/libexec/gpg2keys_ldap' should tell you. :)  There is an
option at compile time to include it, but it's off by default so if
you're using the package you'll have to build it yourself.

IME the keyserver is queryable by ldap, but it doesn't seem to
do anything with updates to my key via --send-keys. I haven't done an
exhaustive test though, so this could be wrong.

>>> It's also the ONLY keyserver I've seen that supports photo IDs, and
>>> actually uses the web interface to show you the person.
>> The SKS servers (i.e. pretty much everything that isn't the GD) do
>> support photo IDs, but they do not use the web interface to show you
>> the photo. displays photos as well. I think it would be nice
if the SKS keyservers added this feature since it would definitely make
figuring out if the key(s) I found in a search are for the person I'm
looking for, but I don't care enough about it to dig into the code, too
many other things to do. :)

>> Are you sure about that?  "clean" strips off useless signatures
>> (useless being defined as an invalid signature, a superseded
>> signature, a revoked signature, and a signature from a key that isn't
>> present on the keyring).  Signatures from keys that are present, but
>> have no trust value are not stripped off.

It's actually kind of interesting timing that Dan brought this up since
this aspect of the clean function has been bugging me as well. I like
the fact that 'clean' strips off all but the latest of duplicate sigs,
and in particular with the keyserver I like that it does this,
but leaves the latest one even if it's expired. What I don't like is
that the generic 'clean' (and by this I mean import-clean and
export-clean in import/export/keyserver options) also strips off
signatures for keys that are not already present in the keyring. IMNSHO
it would be better if the default clean did everything it does now
_except_ stripping sigs for absent keys, and that the latter was a new,
additional layer. If that's not possible for backwards compatibility
reasons then a new feature to do the "clean everything as it does now
except stripping signatures for absent keys" would be ok too.

The reason I'd like to see signatures for absent keys by default is that
it gives me an idea of how well signed the key is. I've learned to use
3rd party tools like for this, but I can't always
rely on 3rd party stuff to be completely up to date.

In regards to Dan's other question (automatically fetch keys for
checking signatures) one easy way to implement this would be for
--check-sigs (and in fact, other gnupg commands generally) to honor
--keyserver-options auto-key-retrieve.




	... and that's just a little bit of history repeating.
			-- Propellerheads

	Improve the effectiveness of your Internet presence with
	a domain name makeover!

More information about the Gnupg-users mailing list