gpgme-tool socket interface

W. Trevor King wking at drexel.edu
Sat Apr 7 17:23:58 CEST 2012


On Sat, Apr 07, 2012 at 12:16:00PM +0200, Werner Koch wrote:
> On Fri,  6 Apr 2012 21:38, wking at drexel.edu said:
> 
> > 1) Creating an Assuan server that listens at a standard socket
> >    (e.g. ~/.assuan/S.<program-name>) should probably be part of
> >    libassuan.  Then I could avoid duplicating a lot of gpg-agent.c's
> >    socket handling code.  Should I move that code over?
> 
> In theory you are right.  However, I prefer to keep the code separated.

Separated is fine, duplicated is bad ;).  I'd like to duplicate
gpg-agent's approach, since it's a well-tested example of doing what I
want gpgme-tool to do, but if you want me to implement that approach
from scratch, I could try and do that instead…  Do you mean "don't copy
code from GnuPG into libassuan" or "don't put this socket handling
stuff in libassuan"?

> > 2) gnupg/jnlib is ~10k lines, which seems big enough to be a
> >    stand-alone library to me ;).  If you don't want to release it as a
> 
> GIT master has no more jnlib; it is part of gnupg/common.

Ah, yes.  I've pulled the Git repo now instead of looking at the
tarball used to install GnuPG on my system.

> Marcus and me already talked about having GnuPG runtime library.
> However, a standalone library is a lot of work because you have to
> design a solid and stable API and maintain it for a long time.

You only have to maintain the old API it if people use it ;).  In my
opinion, reducing code duplication would make it easier to maintain
the libassuan ecosystem, not harder.

> Thus the current idea is to gradually move certain functionality
> over to libgpg-error and eventually rename libgpg-error.

Socket handling and filename creation are probably not going to end up
in libgpg-error, are they?

On Sat, Apr 07, 2012 at 12:30:56PM +0200, Werner Koch wrote:
> On Fri,  6 Apr 2012 22:25, wking at drexel.edu said:
> 
> > * Cleanup and signal handling (remove_socket, handle_signal, …).  In
> >   order to allow flexible signal handling, there should be stand-alone
> 
> I think it is better to avoid signals as much as we can.  We can't use
> them under Windows anyway and thus we need Assuan commands insteads.

While I agree that `gpg-connect-agent SHUTDOWN` would work as well as
`killall gpg-agent`, some users will still be killing gpg-agent by
shutting down their computer.  On Linux anyway, that means you'll be
getting a SIGTERM, and you'll want to unlink your socket before
exiting.  I don't see a way to do that without using signal handling.
I suppose you could drop Unix sockets entirely in favor of inet
sockets?

-- 
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: 490 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20120407/d7031436/attachment.pgp>


More information about the Gnupg-devel mailing list