(a) a couple of typos in the source code
(b) adds a ctrl command and handling code to enable or disable the fork()
checking that CHIL can do when applications are calling fork() in
their application and using the library from multiple child processes
after the one initialisation.
(c) adds another ctrl command to prevent the initialisation of the CHIL
library from providing mutex-handling callbacks, even if the library
has suitable callbacks already available. This can simplify (and
optimise) applications that do not use multi-threading.
implement it for nCipher hardware. The interface in itself should be
clear enough, but the nCipher implementation is currently not the
best when it comes to getting a passphrase from the user. However,
getting it better is a little hard until a better user interaction
method is create.
Also, use the possibility in req, so we can start to create CSR's with
keys from the nForce box.
WARNING: I've made *no* tests yet, mostly because I didn't implement
this on the machine where I have an nForce box to play with. All I
know is that it compiles cleanly on Linux...
This is correctly taken care of by hwcrhk_init(). While we're at it, give
this engine the official name of the library used (CHIL, for Cryptographic
Hardware Interface Library).
OpenSSL to have to opt out hardware support instead of having to opt
it in. And since the hardware support modules are self-contained and
actually check that the vendor stuff is loadable, it still works as
expected, or at least, so I think...
whatever the underlying API is. It must return (void *) because shared
libraries can expose functions, structures, or whatever. However, some
compilers give loads of warnings about casted function pointers through
this code, so I am explicitly casting them to the right prototypes.
