1. 28 9月, 2019 3 次提交
    • D
      Fix header file include guard names · fbbfd128
      Dr. Matthias St. Pierre 提交于
      Make the include guards consistent by renaming them systematically according
      to the naming conventions below
      
      The public header files (in the 'include/openssl' directory) are not changed
      in 1.1.1, because it is a stable release.
      
      For the private header files files, the guard names try to match the path
      specified in the include directives, with all letters converted to upper case
      and '/' and '.' replaced by '_'. An extra 'OSSL_' is added as prefix.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      fbbfd128
    • D
      Reorganize local header files · b5acbf91
      Dr. Matthias St. Pierre 提交于
      Apart from public and internal header files, there is a third type called
      local header files, which are located next to source files in the source
      directory. Currently, they have different suffixes like
      
        '*_lcl.h', '*_local.h', or '*_int.h'
      
      This commit changes the different suffixes to '*_local.h' uniformly.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      b5acbf91
    • D
      Reorganize private crypto header files · 0c994d54
      Dr. Matthias St. Pierre 提交于
      Currently, there are two different directories which contain internal
      header files of libcrypto which are meant to be shared internally:
      
      While header files in 'include/internal' are intended to be shared
      between libcrypto and libssl, the files in 'crypto/include/internal'
      are intended to be shared inside libcrypto only.
      
      To make things complicated, the include search path is set up in such
      a way that the directive #include "internal/file.h" could refer to
      a file in either of these two directoroes. This makes it necessary
      in some cases to add a '_int.h' suffix to some files to resolve this
      ambiguity:
      
        #include "internal/file.h"      # located in 'include/internal'
        #include "internal/file_int.h"  # located in 'crypto/include/internal'
      
      This commit moves the private crypto headers from
      
        'crypto/include/internal'  to  'include/crypto'
      
      As a result, the include directives become unambiguous
      
        #include "internal/file.h"       # located in 'include/internal'
        #include "crypto/file.h"         # located in 'include/crypto'
      
      hence the superfluous '_int.h' suffixes can be stripped.
      
      The files 'store_int.h' and 'store.h' need to be treated specially;
      they are joined into a single file.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9681)
      0c994d54
  2. 10 9月, 2019 1 次提交
  3. 01 8月, 2019 1 次提交
  4. 11 9月, 2018 1 次提交
  5. 14 7月, 2018 1 次提交
  6. 12 7月, 2018 2 次提交
  7. 22 6月, 2018 1 次提交
  8. 13 10月, 2017 1 次提交
  9. 21 8月, 2017 1 次提交
  10. 31 7月, 2017 3 次提交
  11. 28 2月, 2017 2 次提交
  12. 01 2月, 2017 2 次提交
  13. 13 9月, 2016 1 次提交
  14. 20 7月, 2016 1 次提交
  15. 18 5月, 2016 1 次提交
  16. 01 3月, 2016 1 次提交
    • M
      Fix BN_hex2bn/BN_dec2bn NULL ptr/heap corruption · 99ba9fd0
      Matt Caswell 提交于
      In the BN_hex2bn function the number of hex digits is calculated using
      an int value |i|. Later |bn_expand| is called with a value of |i * 4|.
      For large values of |i| this can result in |bn_expand| not allocating any
      memory because |i * 4| is negative. This leaves ret->d as NULL leading
      to a subsequent NULL ptr deref. For very large values of |i|, the
      calculation |i * 4| could be a positive value smaller than |i|. In this
      case memory is allocated to ret->d, but it is insufficiently sized
      leading to heap corruption. A similar issue exists in BN_dec2bn.
      
      This could have security consequences if BN_hex2bn/BN_dec2bn is ever
      called by user applications with very large untrusted hex/dec data. This is
      anticipated to be a rare occurrence.
      
      All OpenSSL internal usage of this function uses data that is not expected
      to be untrusted, e.g. config file data or application command line
      arguments. If user developed applications generate config file data based
      on untrusted data then it is possible that this could also lead to security
      consequences. This is also anticipated to be a rare.
      
      Issue reported by Guido Vranken.
      
      CVE-2016-0797
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      99ba9fd0
  17. 24 2月, 2016 1 次提交
    • D
      RT4339: Fix handling of <internal/bn_conf.h> · 78c83078
      David Woodhouse 提交于
      The entire contents of <internal/bn_conf.h> are unwanted in the UEFI
      build because we have to do it differently there. To support building
      for both 32-bit and 64-bit platforms without re-running the OpenSSL
      Configure script, the EDK2 environment defines THIRTY_TWO_BIT or
      SIXTY_FOUR_BIT for itself according to the target platform.
      
      The current setup is broken, though. It checks for OPENSSL_SYS_UEFI but
      before it's actually defined, since opensslconf.h hasn't yet been
      included.
      
      Let's fix that by including opensslconf.h. And also let's move the
      bn_conf.h doesn't even need to *exist* in the UEFI build environment.
      
      This is also GH PR736.
      Signed-off-by: NRich Salz <rsalz@openssl.org>
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      78c83078
  18. 31 1月, 2016 1 次提交
  19. 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
  20. 25 1月, 2016 1 次提交
  21. 01 12月, 2015 1 次提交
  22. 31 10月, 2015 1 次提交
  23. 26 5月, 2015 1 次提交
  24. 06 5月, 2015 1 次提交
  25. 25 3月, 2015 1 次提交
  26. 22 1月, 2015 1 次提交
  27. 31 12月, 2014 1 次提交
  28. 15 12月, 2014 1 次提交
  29. 09 12月, 2014 3 次提交
  30. 01 6月, 2014 2 次提交