common.c and getpass.c and thread safety, zeroization

[Jeffrey Walton]

The caching that is occurring -  via static data declaration - with
respect to passwords in common.c and getpass.c appears to leak
sensitive material. At minimum, routines are not following best
practices regarding sensitive data such as passwords and PINs.

For example, if a password is only needed once, its unclear how to
zeroize the memory in a static buffer from an invoked function after
its use. Its also unclear how to specify that sensitive material, such
as a password or PIN, *not* be cached.

In addition, a static buffer in used in getpass.c. getline(3) states
it will realloc if the required buffer for the password is too small.
How does GnuTLS zeroize the memory in calls to getpass.c when the
static buffer needs to grow? getline(3) makes no guarantees the data
will be sanitized.

Finally, the static buffers are not thread safe in its current
implementation. stdin and stout out might be serialized, but threads
which are concurrently executing routines such as getpass.c will leave
the shared buffer in an unknown state since the buffer might change
before the caller can copy out the correct [expected?] password.