1. 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
  2. 08 1月, 2016 1 次提交
  3. 07 1月, 2016 1 次提交
  4. 10 11月, 2015 1 次提交
  5. 31 10月, 2015 1 次提交
  6. 14 5月, 2015 1 次提交
  7. 01 5月, 2015 1 次提交
    • R
      free cleanup almost the finale · 4b45c6e5
      Rich Salz 提交于
      Add OPENSSL_clear_free which merges cleanse and free.
      (Names was picked to be similar to BN_clear_free, etc.)
      Removed OPENSSL_freeFunc macro.
      Fixed the small simple ones that are left:
              CRYPTO_free CRYPTO_free_locked OPENSSL_free_locked
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      4b45c6e5
  8. 25 3月, 2015 1 次提交
    • M
      Deprecate RAND_pseudo_bytes · 302d38e3
      Matt Caswell 提交于
      The justification for RAND_pseudo_bytes is somewhat dubious, and the reality
      is that it is frequently being misused. RAND_bytes and RAND_pseudo_bytes in
      the default implementation both end up calling ssleay_rand_bytes. Both may
      return -1 in an error condition. If there is insufficient entropy then
      both will return 0, but RAND_bytes will additionally add an error to the
      error queue. They both return 1 on success.
      Therefore the fundamental difference between the two is that one will add an
      error to the error queue with insufficient entory whilst the other will not.
      Frequently there are constructions of this form:
      
      if(RAND_pseudo_bytes(...) <= 1)
      	goto err;
      
      In the above form insufficient entropy is treated as an error anyway, so
      RAND_bytes is probably the better form to use.
      
      This form is also seen:
      if(!RAND_pseudo_bytes(...))
      	goto err;
      
      This is technically not correct at all since a -1 return value is
      incorrectly handled - but this form will also treat insufficient entropy as
      an error.
      
      Within libssl it is required that you have correctly seeded your entropy
      pool and so there seems little benefit in using RAND_pseudo_bytes.
      Similarly in libcrypto many operations also require a correctly seeded
      entropy pool and so in most interesting cases you would be better off
      using RAND_bytes anyway. There is a significant risk of RAND_pseudo_bytes
      being incorrectly used in scenarios where security can be compromised by
      insufficient entropy.
      
      If you are not using the default implementation, then most engines use the
      same function to implement RAND_bytes and RAND_pseudo_bytes in any case.
      
      Given its misuse, limited benefit, and potential to compromise security,
      RAND_pseudo_bytes has been deprecated.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      302d38e3
  9. 22 1月, 2015 1 次提交
  10. 11 1月, 2014 1 次提交
  11. 23 8月, 2012 1 次提交
    • D
      PR: 2786 · 0db17852
      Dr. Stephen Henson 提交于
      Reported by: Tomas Mraz <tmraz@redhat.com>
      
      Treat a NULL value passed to drbg_free_entropy callback as non-op. This
      can happen if the call to fips_get_entropy fails.
      0db17852
  12. 22 6月, 2011 1 次提交
  13. 24 4月, 2011 2 次提交
  14. 21 4月, 2011 1 次提交
  15. 07 4月, 2011 1 次提交
  16. 05 4月, 2011 1 次提交
  17. 26 1月, 2011 1 次提交
  18. 12 11月, 2008 1 次提交
  19. 02 11月, 2008 1 次提交
  20. 24 9月, 2007 1 次提交
  21. 03 3月, 2007 1 次提交
    • L
      Initialize "buf" to 0 to make valgrind happy :-) · 1fcfa222
      Lutz Jänicke 提交于
      Note: the RAND_bytes() manual page says:
       RAND_bytes() puts num cryptographically strong pseudo-random bytes into buf.
      It does not talk about using the previous contents of buf so we are working
      as documented.
      1fcfa222
  22. 31 1月, 2003 1 次提交
  23. 26 9月, 2001 1 次提交
    • G
      This commits changes to various parts of libcrypto required by the recent · cb78486d
      Geoff Thorpe 提交于
      ENGINE surgery. DH, DSA, RAND, and RSA now use *both* "method" and ENGINE
      pointers to manage their hooking with ENGINE. Previously their use of
      "method" pointers was replaced by use of ENGINE references. See
      crypto/engine/README for details.
      
      Also, remove the ENGINE iterations from evp_test - even when the
      cipher/digest code is committed in, this functionality would require a
      different set of API calls.
      cb78486d
  24. 21 6月, 2001 1 次提交
    • D
      · ed5538dc
      Dr. Stephen Henson 提交于
      Fix memory leak when RAND is used: need to cleanup
      RANDs ENGINE reference in ENGINE_cleanup().
      ed5538dc
  25. 30 4月, 2001 1 次提交
  26. 18 4月, 2001 1 次提交
    • G
      Some more tweaks from ENGINE code. · a4a9d97a
      Geoff Thorpe 提交于
      Previously RAND_get_rand_method was returning a non-const pointer, but it
      should be const. As with all other such cases, METHOD pointers are stored and
      returned as "const". The only methods one should be able to alter are methods
      "local" to the relevant code, in which case a non-const handle to the methods
      should already exist.
      
      This change has been forced by the constifying of the ENGINE code (before
      which RAND_METHOD was the only method pointer in an ENGINE structure that was
      not constant).
      a4a9d97a
  27. 27 10月, 2000 1 次提交
  28. 02 3月, 2000 1 次提交
  29. 19 2月, 2000 1 次提交
  30. 16 1月, 2000 1 次提交
  31. 14 1月, 2000 1 次提交
  32. 12 9月, 1999 1 次提交
    • A
      Initial support for MacOS. · 17f389bb
      Andy Polyakov 提交于
      This will soon be complemented with MacOS specific source code files and
      INSTALL.MacOS.
      
      I (Andy) have decided to get rid of a number of #include <sys/types.h>.
      I've verified it's ok (both by examining /usr/include/*.h and compiling)
      on a number of Unix platforms. Unfortunately I don't have Windows box
      to verify this on. I really appreciate if somebody could try to compile
      it and contact me a.s.a.p. in case a problem occurs.
      
      Submitted by: Roy Wood <roy@centricsystems.ca>
      Reviewed by: Andy Polyakov <appro@fy.chalmers.se>
      17f389bb
  33. 24 4月, 1999 1 次提交
  34. 20 4月, 1999 1 次提交
  35. 10 2月, 1999 1 次提交
  36. 22 12月, 1998 1 次提交
  37. 21 12月, 1998 3 次提交