Geoff Thorpe 05d909c549 * Migrate the engine code's Malloc + Free calls to the newer
OPENSSL_malloc and OPENSSL_free.

* 3 "normal" files (crypto/rsa/rsa_lib.c, crypto/dsa/dsa_lib.c
  and crypto/dh/dh_lib.c) had their Malloc's and Free's missed
  when Richard merged the changes across to this branch -
  probably because those files have been changed in this branch
  and gave some grief to the merge - so I've changed them
  manually here.
2000-06-09 11:42:02 +00:00
..

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 ...