FYI, in a few weeks I'll have some time to actually implement and
submit patches. I'll attempt to identify useful points for automatic
self-initialization (any hints as to commonly used first calls, not
counting the callback setters, would be welcomed). I'll also have to
spend sometime with the build system to autodetect correct build
options. The rest should be simple enough.
I do plan to stay away from RNG and fork-safety issues, except for
re-seeding or perturbing the PRNG on the child-side of fork().
I'm not sure how to test, except for, perhaps, building two sets of
shared objects with different SONAMEs so as to be able to load two
instances of the same libraries (and their callers) in one process.
Some ideas as to what to test for would be nice. I was thinking of
instrumenting OpenSSL entry points with calls to a utility that uses
dladdr() and stack walkers to ensure that each {caller, OpenSSL
instance} pair are always paired up correctly and no caller
inappropriately calls a different OpenSSL instance. Would such a test
need to be in-tree and build-time configurable? But this seems more
like a test of the run-time linker loader than a test of OpenSSL.
Ideas on how to test are welcomed.
That's the plan. If any of you see anything wrong with it, please
save me time and effort by letting me know.
Nico
--
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
