1. 07 6月, 2016 1 次提交
    • M
      Document the issue with threads and dlopen() · c796e021
      Matt Caswell 提交于
      If using threads and OpenSSL is loaded via dlopen(), and subsequently
      closed again via dlclose() *before* the threads are destroyed, then
      OpenSSL will not free up the per thread resources. We need to document
      this restriction, and provide some guidance on what to do about it.
      
      I did some testing and discovered/verified a few of things (at least
      this is the behaviour on Linux):
      
      - Using OpenSSL via dlopen in a mutli-threaded app does leak memory if
      threads are destroyed after dlcose() is called.
      - In a single threaded environment, or if threads are destroyed prior to
      dlclose() being called, then no memory is leaked
      - Using the RTLD_NODELETE flag to dlopen solves the above problem
      - Interestingly the OpenSSL atexit() handler gets called when dlclose()
      is called rather than at application exit (I was worred that it might crash
      if there was an atexit() handler for a function that has been unloaded)
      - RTLD_NODELETE is a non-standard flag - but it does seem to be fairly
      widely supported. As far as I could determine (via google), at least Linux,
      Solaris, OpenBSD, FreeBSD, HP-UX all seem to support it.
      
      I also tested on Windows (using LoadLibrary instead of dlopen and
      FreeLibrary instead of dlclose) and experienced similar behaviour, except
      that (AFAIK) there is no equivalent of RTLD_NODELETE on Windows.
      
      GitHub Issue #653
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      c796e021
  2. 06 6月, 2016 2 次提交
  3. 05 6月, 2016 2 次提交
  4. 04 6月, 2016 1 次提交
    • M
      Fix documentation error in x509 app certopt flag · 39a47008
      Matt Caswell 提交于
      According to the x509 man page in the section discussing -certopt it says
      that the ca_default option is the same as that used by the ca utility and
      (amongst other things) has the effect of suppressing printing of the
      signature - but in fact it doesn't. This error seems to have been present
      since the documentation was written back in 2001. It never had this effect.
      
      The default config file sets the certopt value to ca_default. The ca utility
      takes that and THEN adds additional options to suppress printing of the
      signature. So the ca utility DOES suppress printing of the signature - but
      it is not as a result of using the ca_default option.
      
      GitHub Issue #247
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      39a47008
  5. 01 6月, 2016 8 次提交
  6. 31 5月, 2016 1 次提交
  7. 30 5月, 2016 6 次提交
  8. 27 5月, 2016 1 次提交
  9. 24 5月, 2016 1 次提交
  10. 23 5月, 2016 3 次提交
  11. 21 5月, 2016 1 次提交
  12. 20 5月, 2016 3 次提交
  13. 19 5月, 2016 9 次提交
  14. 17 5月, 2016 1 次提交