gpgme-tool socket interface

[W. Trevor King]

With Python 3.3 officially released, I can now use socket.sendmsg() to
send FDs to Assuan servers listening on Unix sockets.  This means
pgp-mime can communicate with a persistent gpgme-tool server (sweet!),
where I used to use subprocess.Popen() to fork/exec a client for every
transaction and pass the file descriptors via process inheritance
(yuck!).

This works on my local system, with a patched version of gpgme-tool
that uses the cues off the existing -s/--server option to run as a
fork/exec server listening on a Unix socket instead of running as a
pipe server.

The problem is getting this to a releasable state without forking
gpgme-tool.  We discussed this back in April [1], but I was pushing
for additional socket-server utility code in libassuan, and that
didn't seem to be going over very well.  I still think that's the best
way to go, but if changes to GPGME are more likely to be accepted, I
can go that way instead.  I'll volunteer myself to work up patches for
any of the following:

a) libassuan: Some variation on my original suggestion: a helper
   function to spawn an Assuan server (either pipe or socket) which
   handles all the usual setup/teardown internally.  Both gpg-agent
   and gpgme-tool would then use this function, so it would have to be
   sufficiently flexible to handle both cases.  API to-be-determined.

b) gpgme: copy gpg-agent's socket handling code into gpgme-tool (with
   copy-paste commits for proper attribution, followed by integration
   commits by me).

c) same as (b), but I'll write up the socket handling from scratch
   (man pages, etc.) to keep the code-base distinct from GnuPG.  Since
   I can't look at gpg-agent's code, I'll probably someone else to
   handle the MS Windows side, if people want that to be supported.
   Since we're just adding functionality, I see no reason why Windows
   *must* be supported.

d) Other approaches?

Of course, if someone else wants to do the legwork, I'm happy to sit
back and use your code ;).

Cheers,
Trevor

[1]: http://thread.gmane.org/gmane.comp.encryption.gpg.devel/16843/focus=16865

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20121007/71689974/attachment.pgp>