Status of GPA and GPGME

David Shaw dshaw@jabberwocky.com
Tue Aug 27 00:14:02 2002


On Tue, Aug 27, 2002 at 12:05:24AM +0200, Miguel Coca wrote:
> On Mon, Aug 26, 2002 at 13:19:03 -0400, David Shaw wrote:
> > Currently, this is not complete (and won't be complete in 1.2), so the
> > keyserver plugins system is used for all keyserver types except for HKP
> > (the HTTP-like servers such as pgp.mit.edu).
> 
> I don't think I've used a keyserver that wasn't HKP, so I don't have first
> hand experience. How much "not complete" is it (or is expected to be for
> 1.2)? Is it usable for LDAP keyservers, for example?

I think I was not clear enough.  What I meant was that the intent is
to eventually have no built-in keyserver support in the gpg binary,
and do all keyserver access through the external helper programs.
Currently, this plan is not complete: in 1.2, HKP is still in the gpg
binary, but all other keyserver types (including LDAP) are external.
There is already code for an external HKP handler, but it is not yet
as good as the internal code (it is missing HTTP proxy support).

> > Perhaps it would make sense for gpa or gpgme to call the keyserver
> > helpers directly, rather than through GnuPG?
> 
> Yes, it makes sense. There is only one problem on my part. GPA should run on
> both Unix and Windows. So, it would need an interface for calling the helper
> and communicating with it for each platform. Gpgme already uses something
> like that for calling gpg, so perhaps it would be better (less work and
> duplication of code) to do it there.

That sounds reasonable, if it could be done in gpgme.  GnuPG has the
same portability issue, so the keyserver helper programs are all
written to accept commands via a pipe or via a temp file.

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson