Pinentry linking to libassuan? (was: Add inside-Emacs mode to GUI pinentry programs)

[Daniel Kahn Gillmor]

Hi there--

On Fri 2015-06-05 05:31:23 -0400, Werner Koch wrote:
> Originally Pinentry should be mostly self-standing but today this is
> only true for the plain curses, tty and Windows versions.  Most users
> however build one of the real GUI versions with all their large
> dependencies.

For users of graphical environments, this seems likely to be the right
choice.

> The question is whether we should keep on using our much stripped down
> versions of libassuan and libgpg-error or switch over to use libassuan
> and libgpg-error directly.  In fact, both libraries are required by
> GnuPG itself and also be any software using GPGME.  Thus we can expect
> that such a change won't introduce any new platform problems.

I'd be happy to switch to libassuan + gcrypt in those environments,
since those libraries are likely already on the system (and pinentry is
really usually expected to be invoked by gpg-agent, which itself depends
on libassuan and gcrypt).

That said, I'd like to try to minimize the number of dependencies for
the non-graphical clients in normal circumstances.  I've filed:

  https://bugs.debian.org/787883

to track doing that in debian.  Is there a way to make a single build of
the pinentry tree, but to only enable libsecret for gtk2, qt4, and
gnome3 and leave it out for tty and curses?  if not, i guess i can just
./configure twice and build different variants in the different
configurations.

> However, we should also link to Libgcrypt to make use of its secure
> memory code - if that is something we should keep on using. It would
> also be possible to do without and make sure that the passphrase is only
> stored at one place which we would manually clear as needed.  Frankly, I
> think that the mlock-ed memory area is not useful anymore because it
> does not help against hibernation.  To mitigate the swapping problem an
> encrypted swap partition is anyway much easier and safer.

Doing away with mlocking entirely would certainly simplify the pinentry
codebase.

        --dkg