GNOME Bugzilla – Bug 159918
Validate keyserver uris
Last modified: 2005-04-25 00:31:17 UTC
In the preferences window we need to validate the keyserver uris. This can be done by parsing the uri and then checking to see if the appropriate executable plugin works.
What constitutes a valid URI? pgp.mit.edu? http://pgp.mit.edu? Is there documentation available on the gpg plugins we're using?
The GPG keys plugins are distributed with GPG. They handle interaction with a certain type of keyserver. The plugins are named like this: gpgkeys_<scheme> So the plugin for ldap uris is called 'gpgkeys_ldap'. These plugins are found in the /usr/lib/gnupg/gpgkeys_ldap or such directory. In the code plugins without a scheme use a default scheme (ldap, last time i checked). So I think, basically validating it means checking that the URI parses, and we have the plugin for that scheme.
Right now, there's an unimplemented validate function in seahorse-ldap-source.c. Are we going to keep the validate functions burried in the sources it seems like a lot of the validation is common to all protocols? Would the validate code work something like: * Starts with valid protocol i.e. ldap:// hkn:// etc * Portion after protocol contains at least one dot "." * Portion after protocol doesn't contain any non-escaped US-ASCII excluded characters: 2.4.3. Excluded US-ASCII Characters from http://www.ietf.org/rfc/rfc2396.txt Any other tests needed? Resources: http://www.w3.org/Addressing/ http://www.ietf.org/rfc/rfc2396.txt
The idea is to have seahorse_server_source_validate_uri (or whatever it's called) call each of the specific remote source uri validation functions in turn (ie: seahorse_ldap_source_validate_uri). Currently we only have native support for LDAP, but I'll be putting back the support for the GPG plugins eventually. This type of scheme would also allow us to hand off the URIs to the correct remote source class. URIs without a scheme prefix, get a default one added (propably ldap://).
Committed validation code. Added a keyserver creation dialog. BTW, we don't support the gpgkeys_* plugins anymore. It's much more efficient and reliable for us to interact with the keyservers directly. If there comes a time when it makes sense for us to use gpgkeys_* we can always resurect the old code and dust it off.