Pinentry: secure memory

[Neal H. Walfield]

Hi,

At Fri, 05 Jun 2015 11:31:23 +0200,
Werner Koch wrote:
> given that pinentry gets more and more complicated it does not anymore
> fulfill its original goal to be small enough to be easily audited.  One
> of the main problem here has been the major changes to Gtk+ over the
> last decade.  And now of Emacs socket code is added as well.
> 
> 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.
> 
> 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.
> 
> 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.

This raises another question: do the secure widgets actually increase
security?  Recall our threat model is someone reading the password
from swap.  Here are two things to consider:

1./ Even pinentry-tty uses buffered I/O to read in the password.
Since libc doesn't mlock the buffers, the password can potentially end
up in unlock memory.  The password also flies through the X server and
functions processing it may end up storing parts of the password on
the stack.  Ensuring that the password is only held in mlocked memory
is a pipe dream.

2./ The secure widgets are based on very old code, which we forked
from, e.g., Gtk+2.  It is possible that bugs have been fixed.  In the
very least it has caused some accessibility issues.  Unfortunately, we
don't have time to continuously merge in changes.  Using the stock
widgets would be easy.

What do others thinK?  Should we use use the stock widgets or do the
secure entry widgets actually increase security?

Thanks,

:) Neal