gcry_control(GCRYCTL_INIT_SECMEM,...)

[Nikos Mavroyanopoulos]

On Thu, Jan 23, 2003 at 07:04:55PM +0100, Werner Koch wrote:

> > library using libgcrypt decides at runtime whether libgcrypt, and in
> > particular secure memory, is needed at all, and 3) the application
> You can't do that because with the Linux kernel you need to run the
> program setuid and drop this privilige as ASAP.  There is no way to
> enclose the secure memory use in a library.

I believe that secure memory should be something exceptional, and not
to be considered standard use of libgcrypt. The benefits are good, but
the problems it has overcome them. Since libgcrypt is usually used by
higher level libraries and probably they are used by a more high interface
library. 

Let's say the gnutls uses libgcrypt, and libkoko uses gnutls to provide a
secure a game connection over the net. We cannot expect the game developer 
to properly initialize libgcrypt. The libraries must be able to easily and properly
initialize libgcrypt (without secure memory). If someone wants secure memory
and stuff he should initialize himself libgcrypt. The current situation
is quite complicated, and can be simplified much by disabling secure memory
by default.

[...]
>   gcry_set_log_handler (my_gcry_logger, NULL);
> 
> Well, there is again the problem who should set this up: the library
> or the application.

Also printing errors to stderr by default is dangerous (stderr is actually
fd 2, and in servers it is not stderr). Libgcrypt might write "please do some
input ..." in someone's database tables. That's why I set the libgcrypt's
verbosity to 0 in gnutls. I believe that a low level library should not expect 
input nor output to the user.

> Salam-Shalom,
>    Werner

-- 
Nikos Mavroyanopoulos