gcry_control(GCRYCTL_INIT_SECMEM,...)

[Werner Koch]

On Thu, 23 Jan 2003 22:32:44 +0200, Nikos Mavroyanopoulos said:

> I believe that secure memory should be something exceptional, and not
> to be considered standard use of libgcrypt. The benefits are good, but

I agree with you.

> and stuff he should initialize himself libgcrypt. The current situation
> is quite complicated, and can be simplified much by disabling secure memory
> by default.

However, this does not solve other initialization problems.  Well, we
could use constructors to trigger them but they are not available on
every platform.  For a single threaded application we don't have any
problems but we can get race conditions in a multi threaded
application.

Okay, I will disable secure memory be default.

> 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

I have to disagree here.  stderr is the designated stream for error
messages and all well behaving software does it like this.
Applications which take stderr as data input are broken (telnet is not
a problem anymore since ssh gets it right).  Even libc writes to
stderr, I don't even need to talk about gnome or kde libs.

OTOH, a library should only print severe error messages and that is
what Libgcrypt does - double initialization is a bug and it is better
to let the programmer/user know about this.  Such diagnostics are
essential for bug tracking.

Regarding the "not enough random bytes available (need %d bytes)\n"
message, you are right. It should be replaced by a callback mechanism.