gcry_control(GCRYCTL_INIT_SECMEM,...)

[Werner Koch]

On Thu, 23 Jan 2003 18:31:21 +0100, Simon Josefsson said:

> It gets complex when 1) the library that uses libgcrypt only
> optionally links with libgcrypt (compile time check) and 2) the

That's easy, you can #ifdefs that or use ELF magic.

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

> implements a network protocol where the stderr print will confuse the
> implementation at the other end and cause it to drop the connection.

I can see that.  The way to avoid this is by setting up an error
handler:

  static void
  my_gcry_logger (void *dummy, int level, const char *fmt, va_list arg_ptr)
  {
    /* optionally do something with LEVEL. */
    vfprintf (whereever, fmt, arg_ptr);
  }

  gcry_set_log_handler (my_gcry_logger, NULL);

Well, there is again the problem who should set this up: the library
or the application.

> Maybe introducing a GCRYCTL_DISABLE_ALREADY_INIT_SECMEM_WARN gcryctl()
> flag would solve it without putting requirements on applications?

Again, if you get this message, something is going wrong.  Libgcrypt
should only be initialzed once.  If you do the init ala GNUTLS,
everything should work fine as long as only one library wants to use
Libgcrypt - it won't work if there is another library which does not
care about setting a different log handler.  Think of GnuCash with its
58 required libs (even more in newer version) - It is likely that
there are 2 libs which like to make use of Libgcrypt.

So what I propose is to do a default init in your library and document
what an application should better do; i.e. initialize Libgcrypt if
at all possible.


Salam-Shalom,

   Werner