testing gcrypt thread-safety

[Daniel Kahn Gillmor]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 891 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20091028/b91049a7/attachment.pgp>