dkg at fifthhorseman
Oct 28, 2009, 2:30 PM
Post #1 of 1
now that i can properly initialize gcrypt in a threaded fashion (thanks,
testing gcrypt thread-safety
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?