1. 13 4月, 2005 3 次提交
  2. 08 4月, 2005 1 次提交
  3. 07 4月, 2005 1 次提交
  4. 23 11月, 2004 1 次提交
  5. 30 8月, 2004 1 次提交
  6. 02 8月, 2004 1 次提交
  7. 01 8月, 2004 1 次提交
  8. 27 7月, 2004 2 次提交
  9. 20 4月, 2004 1 次提交
  10. 06 10月, 2003 1 次提交
  11. 01 5月, 2003 1 次提交
  12. 13 2月, 2003 1 次提交
  13. 11 12月, 2002 2 次提交
  14. 13 11月, 2002 1 次提交
  15. 04 11月, 2002 1 次提交
  16. 28 10月, 2002 1 次提交
  17. 23 9月, 2002 1 次提交
  18. 09 8月, 2002 1 次提交
    • B
      Add ECDH support. · e172d60d
      Bodo Möller 提交于
      Additional changes:
       - use EC_GROUP_get_degree() in apps/req.c
       - add ECDSA and ECDH to apps/speed.c
       - adds support for EC curves over binary fields to ECDSA
       - new function EC_KEY_up_ref() in crypto/ec/ec_key.c
       - reorganize crypto/ecdsa/ecdsatest.c
       - add engine support for ECDH
       - fix a few bugs in ECDSA engine support
      
      Submitted by: Douglas Stebila <douglas.stebila@sun.com>
      e172d60d
  19. 02 8月, 2002 1 次提交
  20. 30 7月, 2002 1 次提交
    • L
      OpenSSL Security Advisory [30 July 2002] · c046fffa
      Lutz Jänicke 提交于
      Changes marked "(CHATS)" were sponsored by the Defense Advanced
      Research Projects Agency (DARPA) and Air Force Research Laboratory,
      Air Force Materiel Command, USAF, under agreement number
      F30602-01-2-0537.
      c046fffa
  21. 14 2月, 2002 1 次提交
  22. 24 11月, 2001 2 次提交
  23. 06 9月, 2001 1 次提交
    • B
      Totally get rid of CRYPTO_LOCK_ERR_HASH. · 78f79235
      Bodo Möller 提交于
      In err.c, flags int_error_hash_set and int_thread_hash_set
      appear superfluous since we can just as well initialize
      int_error_hash and int_thread_hash to NULL.
      
      Change some of the err.c formatting to conform with the rest of
      OpenSSL.
      78f79235
  24. 02 9月, 2001 1 次提交
    • 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
  25. 26 7月, 2001 1 次提交
  26. 19 6月, 2001 1 次提交
  27. 01 6月, 2001 2 次提交
  28. 07 5月, 2001 1 次提交
  29. 20 2月, 2001 1 次提交
  30. 16 12月, 2000 1 次提交
  31. 27 10月, 2000 1 次提交
  32. 21 6月, 2000 1 次提交
    • D
      · 7ef82068
      Dr. Stephen Henson 提交于
      Handle ASN1_SET_OF and PKCS12_STACK_OF using function
      casts in the same way as STACK_OF.
      7ef82068
  33. 20 6月, 2000 1 次提交
  34. 19 6月, 2000 1 次提交