dgoulet at ev0ke.net
Tue Aug 5 14:21:44 CEST 2014
On 05 Aug (10:57:17), Werner Koch wrote:
> On Mon, 4 Aug 2014 22:13, dgoulet at ev0ke.net said:
> > Right now, with current state of libotr, it's the application job to do
> > that which we *do* in our test client.
> > GCRY_THREAD_OPTION_PTHREAD_IMPL;
> I can't see that:
> wk at wheatstone:~/s/libotr$ git branch -v
> * master 3172d79 Use a constant-time memory comparison for safety.
> wk at wheatstone:~/s/libotr$ find . -type f | xargs grep GCRY_THREAD_OPTION
> wk at wheatstone:~/s/libotr$
Oh so sorry, I should have told you that the test suite we are
developing is in an other repository! My mistake! See below.
> >> I recall that we discussed the threading issue some years ago and it
> >> might be that you did some workaround by protecting gcry_ calls with
> >> your own mutexes. That is quite fragile.
> > I don't see any in libotr though.
> I guessed that because I noticed PTHREAD_MUTEX_INITIALIZER in
This is obsolete, you should look at:
> > this is packages in distribution that supports libotr but does not have
> > libgcrypt 1.6 but for system that do supports it, that should be done
> > anyway.
> Well, due to the ABI change (different SO number) it is not a problem to
> install it in addition to 1.5.3.
Yes absolutely, just that the test suite needs to use 1.6 but we can
make it happen with some autoconf magic :).
With 1.5.3, we are hitting this original issue of this thread very fast!
with two threads which I had to use a mutex to synchronize the calls to
This workaround is ok for now. I'll make it work with 1.6 and see if I
can remove that lock.
> > Also, libotr has never claimed to be thread safe but if it happens to be
> > someday, is libgcrypt >= 1.6 "stamped thread safe" ?
> libgcrypt < 1.6 was thread safe as well. As with many libraries you
> were required to install callback. Since 1.6 we have
> /* NOTE: Since Libgcrypt 1.6 the thread callbacks are not anymore
> used. However we keep it to allow for some source code
> compatibility if used in the standard way. */
> Form the manual:
> As mentioned earlier, the Libgcrypt library is thread-safe if you
> adhere to the following requirements:
> * If you use pthread and your applications forks and does not
> directly call exec (even calling stdio functions), all kind of
> problems may occur. Future versions of Libgcrypt will try to
> cleanup using pthread_atfork but even that may lead to problems.
> This is a common problem with almost all applications using
> pthread and fork.
> * The function `gcry_check_version' must be called before any other
> function in the library. To achieve this in multi-threaded
> programs, you must synchronize the memory with respect to other
> threads that also want to use Libgcrypt. For this, it is
> sufficient to call `gcry_check_version' before creating the other
> threads using Libgcrypt(1).
> * Just like the function `gpg_strerror', the function
> `gcry_strerror' is not thread safe. You have to use
> `gpg_strerror_r' instead.
Ah superb! This is very helpful, much appreciate!
> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 603 bytes
Desc: Digital signature
More information about the Gcrypt-devel