9c5ed502ee
already been done for RSA. The others (DSA + RAND) will probably follow in the near future too, but DH is easiest to test with RSA because one can just force the use of the EDH cipher-suites. |
||
---|---|---|
.. | ||
vendor_defns | ||
engine.h | ||
engine_err.c | ||
engine_int.h | ||
engine_lib.c | ||
engine_list.c | ||
engine_openssl.c | ||
enginetest.c | ||
hw_cswift.c | ||
Makefile.ssl | ||
README |
NOTES, THOUGHTS, and EVERYTHING ------------------------------- (1) Maybe ENGINE_get_struct_size() isn't such a good idea. All ENGINEs should be allocated from within OpenSSL (rather than, for example, a loaded DSO). Two reasons, (i) DSOs authors are likely to stash the return value as an assumed constant and so everything will break down horribly when OpenSSL is changed/expanded, (ii) with the structure allocated within OpenSSL, we could handle the case where a DSO *really* wants to close down and lick its wounds even if there are still references because we could simply NULL out the pointers in the structure. If I change this, I should also remember to get rid of the parameter in ENGINE_new() as it would serve no purpose and is likely to confuse. (2) Concurrency and locking ... I made a change to the ENGINE_free code because I spotted a potential hold-up in proceedings (doing too much inside a lock including calling a callback), there may be other bits like this. What do the speed/optimisation freaks think of this aspect of the code and design? There's lots of locking for manipulation functions and I need that to keep things nice and solid, but this manipulation is mostly (de)initialisation, I would think that most run-time locking is purely in the ENGINE_init and ENGINE_finish calls that might be made when getting handles for RSA (and friends') structures, and these would be mostly reference count operations as the functional references should always be 1 or greater at run-time to prevent init/deinit thrashing. (3) Atalla isn't finished quite yet. (4) The DH stuff was added to the CryptoSwift code without testing because it should work trivially and didn't involve adding more of the cropped bits from Rainbow's headers back into the vendor_defns stuff. (Also, randomness should be easy to add soon when I sort the headers out a bit more which would give hw_cswift a full suite). (5) Another make update is probably due ...