1. 28 9月, 2019 2 次提交
    • 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 6 次提交
  3. 09 9月, 2019 1 次提交
  4. 05 9月, 2019 2 次提交
  5. 30 8月, 2019 1 次提交
  6. 24 8月, 2019 1 次提交
  7. 20 8月, 2019 1 次提交
    • P
      Start up DEVRANDOM entropy improvement for older Linux devices. · 3ff98f55
      Pauli 提交于
      Improve handling of low entropy at start up from /dev/urandom by waiting for
      a read(2) call on /dev/random to succeed.  Once one such call has succeeded,
      a shared memory segment is created and persisted as an indicator to other
      processes that /dev/urandom is properly seeded.
      
      This does not fully prevent against attacks weakening the entropy source.
      An attacker who has control of the machine early in its boot sequence
      could create the shared memory segment preventing detection of low entropy
      conditions.  However, this is no worse than the current situation.
      
      An attacker would also be capable of removing the shared memory segment
      and causing seeding to reoccur resulting in a denial of service attack.
      This is partially mitigated by keeping the shared memory alive for the
      duration of the process's existence.  Thus, an attacker would not only need
      to have called call shmctl(2) with the IPC_RMID command but the system
      must subsequently enter a state where no instances of libcrypto exist in
      any process.  Even one long running process will prevent this attack.
      
      The System V shared memory calls used here go back at least as far as
      Linux kernel 2.0.  Linux kernels 4.8 and later, don't have a reliable way
      to detect that /dev/urandom has been properly seeded, so a failure is raised
      for this case (i.e. the getentropy(2) call has already failed).
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/9595)
      
      [manual merge]
      3ff98f55
  8. 19 8月, 2019 2 次提交
  9. 14 8月, 2019 1 次提交
  10. 01 8月, 2019 1 次提交
  11. 23 7月, 2019 2 次提交
  12. 19 6月, 2019 1 次提交
  13. 09 6月, 2019 1 次提交
    • D
      Revert the DEVRANDOM_WAIT feature · ad416c80
      Dr. Matthias St. Pierre 提交于
      The DEVRANDOM_WAIT feature added a select() call to wait for the
      `/dev/random` device to become readable before reading from the
      `/dev/urandom` device. It was introduced in commit 38023b87f037
      in order to mitigate the fact that the `/dev/urandom` device
      does not block until the initial seeding of the kernel CSPRNG
      has completed, contrary to the behaviour of the `getrandom()`
      system call.
      
      It turned out that this change had negative side effects on
      performance which were not acceptable. After some discussion it
      was decided to revert this feature and leave it up to the OS
      resp. the platform maintainer to ensure a proper initialization
      during early boot time.
      
      Fixes #9078
      
      This partially reverts commit 38023b87f037.
      Reviewed-by: NTim Hudson <tjh@openssl.org>
      Reviewed-by: NViktor Dukhovni <viktor@openssl.org>
      
      (cherry picked from commit a08714e18131b1998faa0113e5bd4024044654ac)
      
      (Merged from https://github.com/openssl/openssl/pull/9118)
      ad416c80
  14. 30 5月, 2019 1 次提交
  15. 28 5月, 2019 1 次提交
  16. 02 4月, 2019 3 次提交
  17. 29 3月, 2019 1 次提交
  18. 22 3月, 2019 1 次提交
  19. 15 3月, 2019 1 次提交
  20. 02 3月, 2019 1 次提交
  21. 26 2月, 2019 1 次提交
  22. 25 1月, 2019 1 次提交
  23. 09 11月, 2018 1 次提交
  24. 08 11月, 2018 3 次提交
    • D
      rand_unix.c: open random devices on first use only · abf58ed3
      Dr. Matthias St. Pierre 提交于
      Commit c7504aeb (pr #6432) fixed a regression for applications in
      chroot environments, which compensated the fact that the new OpenSSL CSPRNG
      (based on the NIST DRBG) now reseeds periodically, which the previous
      one didn't. Now the reseeding could fail in the chroot environment if the
      DEVRANDOM devices were not present anymore and no other entropy source
      (e.g. getrandom()) was available.
      
      The solution was to keep the file handles for the DEVRANDOM devices open
      by default. In fact, the fix did more than this, it opened the DEVRANDOM
      devices early and unconditionally in rand_pool_init(), which had the
      unwanted side effect that the devices were opened (and kept open) even
      in cases when they were not used at all, for example when the getrandom()
      system call was available. Due  to a bug (issue #7419) this even happened
      when the feature was disabled by the application.
      
      This commit removes the unconditional opening of all DEVRANDOM devices.
      They will now only be opened (and kept open) on first use. In particular,
      if getrandom() is available, the handles will not be opened unnecessarily.
      
      This change does not introduce a regression for applications compiled for
      libcrypto 1.1.0, because the SSLEAY RNG also seeds on first use. So in the
      above constellation the CSPRNG will only be properly seeded if it is happens
      before the forking and chrooting.
      
      Fixes #7419
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7437)
      
      (cherry picked from commit 8cfc19716c22dac737ec8cfc5f7d085e7c37f4d8)
      abf58ed3
    • D
      Test: link drbgtest statically against libcrypto · c39df745
      Dr. Matthias St. Pierre 提交于
      and remove duplicate rand_drbg_seedlen() implementation again.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7462)
      
      (cherry picked from commit 1c615e4ce97715ae3af9255bc57be32a49687966)
      c39df745
    • P
      Add missing RAND initialisation call. · f7258489
      Pauli 提交于
      Reviewed-by: NBernd Edlinger <bernd.edlinger@hotmail.de>
      (Merged from https://github.com/openssl/openssl/pull/7587)
      
      (cherry picked from commit ac765685d4b08a48cefffc71c434760045154dad)
      f7258489
  25. 07 11月, 2018 2 次提交
  26. 06 11月, 2018 1 次提交