1. 05 9月, 2001 4 次提交
  2. 04 9月, 2001 11 次提交
  3. 03 9月, 2001 5 次提交
  4. 02 9月, 2001 4 次提交
    • G
      Note the "ex_data" changes. · 36026dfc
      Geoff Thorpe 提交于
      36026dfc
    • G
      Make the necessary changes to work with the recent "ex_data" overhaul. · 79aa04ef
      Geoff Thorpe 提交于
      See the commit log message for that for more information.
      
      NB: X509_STORE_CTX's use of "ex_data" support was actually misimplemented
      (initialisation by "memset" won't/can't/doesn't work). This fixes that but
      requires that X509_STORE_CTX_init() be able to handle errors - so its
      prototype has been changed to return 'int' rather than 'void'. All uses of
      that function throughout the source code have been tracked down and
      adjusted.
      79aa04ef
    • G
      First step in fixing "ex_data" support. Warning: big commit log ... · 3a079997
      Geoff Thorpe 提交于
      Currently, this change merely addresses where ex_data indexes are stored
      and managed, and thus fixes the thread-safety issues that existed at that
      level. "Class" code (eg. RSA, DSA, etc) no longer store their own STACKS
      and per-class index counters - all such data is stored inside ex_data.c. So
      rather than passing both STACK+counter to index-management ex_data
      functions, a 'class_index' is instead passed to indicate the class (eg.
      CRYPTO_EX_INDEX_RSA). New classes can be dynamically registered on-the-fly
      and this is also thread-safe inside ex_data.c (though whether the caller
      manages the return value in a thread-safe way is not addressed).
      
      This does not change the "get/set" functions on individual "ex_data"
      structures, and so thread-safety at that level isn't (yet) assured.
      Likewise, the method of getting and storing per-class indexes has not
      changed, so locking may still be required at the "caller" end but is
      nonetheless thread-safe inside "ex_data"'s internal implementation.
      Typically this occurs when code implements a new method of some kind and
      stores its own per-class index in a global variable without locking the
      setting and usage of that variable. If the code in question is likely to be
      used in multiple threads, locking the setting and use of that index is
      still up to the code in question. Possible fixes to this are being
      sketched, but definitely require more major changes to the API itself than
      this change undertakes.
      
      The underlying implementation in ex_data.c has also been modularised so
      that alternative "ex_data" implementations (that control all access to
      state) can be plugged in. Eg. a loaded module can have its implementation
      set to that of the application loaded it - the result being that
      thread-safety and consistency of "ex_data" classes and indexes can be
      maintained in the same place rather than the loaded module using its own
      copy of ex_data support code and state.
      
      Due to the centralisation of "state" with this change, cleanup of all
      "ex_data" state can now be performed properly. Previously all allocation of
      ex_data state was guaranteed to leak - and MemCheck_off() had been used to
      avoid it flagging up the memory debugging. A new function has been added to
      perfrom all this cleanup, CRYPTO_cleanup_all_ex_data(). The "openssl"
      command(s) have been changed to use this cleanup, as have the relevant test
      programs. External application code may want to do so too - failure to
      cleanup will not induce more memory leaking than was the case before, but
      the memory debugging is not tricked into hiding it any more so it may
      "appear" where it previously did not.
      3a079997
    • G
      Only OPENSSL_free() non-NULL pointers. · e19ea557
      Geoff Thorpe 提交于
      e19ea557
  5. 01 9月, 2001 5 次提交
  6. 29 8月, 2001 1 次提交
  7. 28 8月, 2001 3 次提交
  8. 27 8月, 2001 4 次提交
  9. 26 8月, 2001 3 次提交
    • G
      Tidy up some code formatting. · a844e27b
      Geoff Thorpe 提交于
      a844e27b
    • G
      Note the "ERR" changes. · 0783bf15
      Geoff Thorpe 提交于
      0783bf15
    • G
      This changes the "ERR" code to have all access to state (a hash table of · 566bdf2b
      Geoff Thorpe 提交于
      error strings and a hash table storing per-thread error state) go via an
      ERR_FNS function table. The first time an ERR operation occurs, the
      implementation that will be used (from then on) is set to the internal
      "defaults" implementation if it has not already been set. The actual LHASH
      tables are only accessed by this implementation.
      
      This is primarily for modules that can be loaded at run-time and bound into
      an application (or a shared-library version of OpenSSL). If the module has
      its own statically-linked copy of OpenSSL code - this mechanism allows it
      to *not* create and use ERR information in its own linked "ERR" code, but
      instead to use and interact with the state stored in the loader
      (application or shared library). The loader calls ERR_get_implementation()
      and the return value is what the module should use when calling its own
      copy of ERR_set_implementation().
      566bdf2b