
dkg at fifthhorseman
Oct 28, 2009, 2:30 PM
Post #1 of 1
(76 views)
Permalink
|
|
testing gcrypt thread-safety
|
|
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
|