Werner Koch <w...@gnupg.org> wrote: > > > I think that one solution would be to have mailpile use a per-session > > gpg home dir. > > That is an architectural decision. > > BTW, gpg-agent has this --extra-socket feature which distinguishes > between remote and local use (modulo some discussed changes). It would > be easy to extend it in a way that gpg can tell gpg-agent to act as if > it was used via --extra-socket.
Hi Werner! In order to use that in current releases of GnuPG, then Mailpile needs to run its own gpg-agent, correct? And in order to use a custom pinentry as discussed elsewhere? Can I run multiple agents off the same keychain, or do I also need to create a separate gpg home dir for each one? I ask, because although current users of GnuPG are proportionally very few, they are still a group I consider important. I expect many such users to become quite annoyed if Mailpile doesn't integrate cleanly with their existing keychain. Regarding other topics broached on this thread, I think it is very interesting to hear that GPGME is basically the "official" implementation of something that wraps the gpg binary. I hadn't looked deeply enough into GPGME to be aware of this. I will probably take a peek at the GPGME source to see if I missed some more elegant ways to solve things. In particular, both generating keys and editing the UID list on a key are quite gross in Mailpile's wrapper and I wonder if GPGME offers a better implementation? GPGME proponents will be frustrated to hear that this knowledge actually makes me feel much better about Mailpile's decision to wrap gpg directly: it means I've removed two layers of abstraction between my code and gpg! Win! Although supposedly such layers are supposed to help developers (and people will continue to accuse me of NIH and whatnot), in my experience on other projects, they've more often than not been sources of additional architectural constraints and bugs of their own. OpenSSL wrapper libraries for Python are a prime example, for one. More code: more bugs. This is one of the reasons having a native "protocol" such as JSON or Assuan in the gpg binary itself (or the gpg-agent if things move there) appeals to me so much. With a well designed protocol, wrapper libraries almost become unnecessary and layers and layers of code can just be stripped away and discarded. Consider that with a protocol approach, new features in gpg become available immediately to all applications speaking the protocol. With two layers of wrappers, we have to wait for GPGME to get updated and THEN wait for the Python wrappers to get updated. We're all overworked, so removing layers that need to be kept up-to-date and in lockstep is a hugely valuable investment. A well defined protocol also has the potential to eliminate mountains of platform-specific hacks - if you can talk to the protocol server, things work, no matter whether it's a fifo in the file system, stdio or a TCP/IP connection to a remote box. So people can choose the transport that best suits their platform and just get on with "real work". Anyway, I'm very glad this discussion is taking place. In my opinion, if GnuPG wants to be a platform other apps can build on, these interfaces matter a great deal. Whether there are hacks or workarounds is kind of irrelevant; if developers are unhappy they'll just go develop something else. This stuff matters. Thanks for the comments, - Bjarni -- Sent using Mailpile, Free Software from www.mailpile.is
signature.asc
Description: OpenPGP Digital Signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users
