libotr is using it's own secure memory implementation
As stated in ./src/mem.c :
/* Memory allocation routines for libgcrypt. All of the session key * information gets allocated through here, so we can wipe it out when * it's free()d. We don't use the built-in secmem functions of * libgcrypt because you need to declare a fixed amount of it when you * start up. * * Because "secure" and "insecure" allocations from libgcrypt will get * handled the same way (since we're not going to be running as root, * and so won't actually have pinned memory), pretend all allocated * memory (but just from libgcrypt) is requested secure, and wipe it on * free(). */
There are also some gems like
static int otrl_mem_is_secure(const void *p) { return 1; }
or
/* Wipe the memory (in the same way the built-in deallocator in * libgcrypt would) */ memset(real_p, 0xff, n); memset(real_p, 0xaa, n); memset(real_p, 0x55, n); memset(real_p, 0x00, n); free(real_p);
This is dangerous, since a clever compiler can notice that real_p is freed right after memset, and could remove those calls.
I'm quite sure that libcrypt already has everything libotr may want to use to manage memory, without needing to re-invent the wheel.
(from redmine: created on 2014-04-21)
To upload designs, you'll need to enable LFS and have admin enable hashed storage. More information