testing gcrypt thread-safety

[Daniel Kahn Gillmor-7]

now that i can properly initialize gcrypt in a threaded fashion (thanks,
Werner!), i'm curious what commands might be particularly vulnerable to
uninitialized threadsafety features.

For example, it appears the registering new ciphers, digests, or
asymmetric algorithms use mutex-based locking, as does secmem and
fips-mode.  Is there other functionality that might be vulnerable?

I don't see any code in the tests/ directory which exercises this stuff,
but i'd be willing to write a test if anyone has a particular feature
that they think would be worth testing against threadsafe initialization.

i'm aware that threadsafety issues are difficult to make reliably 100%
reproducible test cases for, but i figure if we make simple test case,
even a 1% failure rate (assuming folks who build the tool actually run
the test suite and report their errors) would be worth having.

Suggestions for what to test?

        --dkg



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