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