1. 23 Nov, 2018 3 commits
    • Richard Levitte's avatar
      Change tarball making procedure · 48c813ef
      Richard Levitte authored
      
      
      Since recently, OpenSSL tarballs are produced with 'make tar' rather
      than 'make dist', as the latter has turned out to be more troublesome
      than useful.
      
      The next step to look at is why we would need to configure at all to
      produce a Makefile just to produce a tarball.  After all, the tarball
      should now only contain source files that are present even without
      configuring.
      
      Furthermore, the current method for producing tarballs is a bit
      complex, and can be greatly simplified with the right tools.  Since we
      have everything versioned with git, we might as well use the tool that
      comes with it.
      
      Added: util/mktar.sh, a simple script to produce OpenSSL tarballs.  It
      takes the options --name to modify the prefix of the distribution, and
      --tarfile tp modify the tarball file name specifically.
      
      This also adds a few entries in .gitattributes to specify files that
      should never end up in a distribution tarball.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/...
      48c813ef
    • Richard Levitte's avatar
      Add an error message test recipes for system error messages · a9334a49
      Richard Levitte authored
      
      
      This ensures we collected them properly and and as completely as can
      be tested safely.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7681)
      
      (cherry picked from commit 4b801fdcf4c25f44374eb18cb18f36d904975edd)
      a9334a49
    • Richard Levitte's avatar
      Smarter build of system error text database · cae2a7ca
      Richard Levitte authored
      
      
      We stored copies of the system error texts in a fixed line size array,
      which is a huge waste.  Instead, use a static memory pool and pack all
      the string in there.  The wasted space at the end, if any, gives us
      some leeway for longer strings than we have measured so far.
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/7681)
      
      (cherry picked from commit 2c5b6bbb6797242f43b5a986e1c018943e5c1305)
      cae2a7ca
  2. 22 Nov, 2018 1 commit
  3. 21 Nov, 2018 2 commits
  4. 20 Nov, 2018 5 commits
  5. 19 Nov, 2018 2 commits
  6. 16 Nov, 2018 2 commits
  7. 15 Nov, 2018 1 commit
  8. 14 Nov, 2018 2 commits
  9. 13 Nov, 2018 4 commits
  10. 12 Nov, 2018 9 commits
  11. 10 Nov, 2018 3 commits
  12. 09 Nov, 2018 5 commits
  13. 08 Nov, 2018 1 commit
    • Dr. Matthias St. Pierre's avatar
      rand_unix.c: open random devices on first use only · abf58ed3
      Dr. Matthias St. Pierre authored
      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: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/7437)
      
      (cherry picked from commit 8cfc19716c22dac737ec8cfc5f7d085e7c37f4d8)
      abf58ed3