1. 26 5月, 2023 1 次提交
  2. 12 4月, 2023 2 次提交
  3. 10 8月, 2021 1 次提交
  4. 17 3月, 2020 1 次提交
  5. 07 1月, 2020 1 次提交
    • M
      Don't store an HMAC key for longer than we need · 16d92fa8
      Matt Caswell 提交于
      The HMAC_CTX structure stores the original key in case the ctx is reused
      without changing the key.
      
      However, HMAC_Init_ex() checks its parameters such that the only code path
      where the stored key is ever used is in the case where HMAC_Init_ex is
      called with a NULL key and an explicit md is provided which is the same as
      the md that was provided previously. But in that case we can actually reuse
      the pre-digested key that we calculated last time, so we can refactor the
      code not to use the stored key at all.
      
      With that refactor done it is no longer necessary to store the key in the
      ctx at all. This means that long running ctx's will not keep the key in
      memory for any longer than required. Note though that the digested key
      *is* still kept in memory for the duration of the life of the ctx.
      
      Fixes #10743
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
      (Merged from https://github.com/openssl/openssl/pull/10763)
      16d92fa8
  6. 28 9月, 2019 2 次提交
  7. 04 9月, 2018 1 次提交
  8. 22 6月, 2018 1 次提交
  9. 18 5月, 2016 1 次提交
  10. 17 2月, 2016 1 次提交
  11. 27 1月, 2016 1 次提交
    • R
      Remove /* foo.c */ comments · 34980760
      Rich Salz 提交于
      This was done by the following
              find . -name '*.[ch]' | /tmp/pl
      where /tmp/pl is the following three-line script:
              print unless $. == 1 && m@/\* .*\.[ch] \*/@;
              close ARGV if eof; # Close file to reset $.
      
      And then some hand-editing of other files.
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      34980760
  12. 08 12月, 2015 2 次提交
  13. 01 4月, 2015 1 次提交
  14. 22 1月, 2015 1 次提交
  15. 04 12月, 2014 1 次提交
  16. 30 4月, 2011 1 次提交
    • D
      Initial "opaque SSL" framework. If an application defines · 08557cf2
      Dr. Stephen Henson 提交于
      OPENSSL_NO_SSL_INTERN all ssl related structures are opaque
      and internals cannot be directly accessed. Many applications
      will need some modification to support this and most likely some
      additional functions added to OpenSSL.
      
      The advantage of this option is that any application supporting
      it will still be binary compatible if SSL structures change.
      08557cf2
  17. 10 11月, 2001 1 次提交
  18. 21 9月, 2001 1 次提交
  19. 20 2月, 2001 1 次提交
    • R
      Make all configuration macros available for application by making · cf1b7d96
      Richard Levitte 提交于
      sure they are available in opensslconf.h, by giving them names starting
      with "OPENSSL_" to avoid conflicts with other packages and by making
      sure e_os2.h will cover all platform-specific cases together with
      opensslconf.h.
      
      I've checked fairly well that nothing breaks with this (apart from
      external software that will adapt if they have used something like
      NO_KRB5), but I can't guarantee it completely, so a review of this
      change would be a good thing.
      cf1b7d96
  20. 18 12月, 2000 1 次提交
  21. 21 9月, 2000 1 次提交
  22. 21 2月, 2000 1 次提交
  23. 23 4月, 1999 1 次提交
  24. 18 4月, 1999 1 次提交
  25. 31 3月, 1999 1 次提交
  26. 21 12月, 1998 2 次提交