gcry_control(GCRYCTL_INIT_SECMEM,...)

[Nikos Mavroyanopoulos]

On Fri, Jan 24, 2003 at 10:58:00AM +0100, Werner Koch wrote:

> > 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.

Is calling gcry_control (GCRYCTL_INITIALIZATION_FINISHED, NULL,0)
sufficient for the other initialization stuff? If yes then
the only code that a library has to call is
if (gcry_control( GCRYCTL_ANY_INITIALIZATION_P) == 0)
   gcry_control(GCRYCTL_INITIALIZATION_FINISHED, NULL,0)

This can be easily moved to a function on startup that is
not thread safe (ie in gnutls is gnutls_global_init).
Other libraries should handle it similary, and there will be
no race conditions.

> > 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.

Ok, but I think that these severe errors should be followed by an
abort() call or something like that. Other errors should only be
printed by the callback mechanism (which is available).

> _______________________________________________
> Gcrypt-devel mailing list
> Gcrypt-devel@gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gcrypt-devel
> 

-- 
Nikos Mavroyanopoulos