1. 08 7月, 2016 1 次提交
  2. 19 6月, 2016 1 次提交
  3. 13 6月, 2016 1 次提交
  4. 01 6月, 2016 2 次提交
  5. 27 5月, 2016 2 次提交
    • M
      Fix s_client/s_server waiting for stdin on Windows · 75dd6c1a
      Matt Caswell 提交于
      On Windows we were using the function _kbhit() to determine whether there
      was input waiting in stdin for us to read. Actually all this does is work
      out whether there is a keyboard press event waiting to be processed in the
      input buffer. This only seems to work in a standard Windows console (not
      Msys console) and also doesn't work if you redirect the input from some
      other source (as we do in TLSProxy tests). This commit changes things to
      work differently depending on whether we are on the Windows console or not.
      
      RT#4255
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      75dd6c1a
    • M
      Fix some s_server issues on Windows · 384f08dc
      Matt Caswell 提交于
      In s_server we call BIO_sock_should_retry() to determine the state of the
      socket and work out whether we should retry an operation on it or not.
      However if you leave it too long to call this then other operations may
      have occurred in the meantime which affect the result. Therefore we should
      call it early and remember the result for when we need to use it. This fixes
      a test problem on Windows.
      
      Another issue with s_server on Windows is that some of output to stdout does
      not get displayed immediately. Apparently more liberal use of BIO_flush is
      required.
      
      RT#4255
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      384f08dc
  6. 24 5月, 2016 1 次提交
  7. 18 5月, 2016 3 次提交
  8. 06 5月, 2016 1 次提交
    • M
      Handle no async jobs in libssl · fc7f190c
      Matt Caswell 提交于
      If the application has limited the size of the async pool using
      ASYNC_init_thread() then we could run out of jobs while trying to start a
      libssl io operation. However libssl was failing to handle this and treating
      it like a fatal error. It should not be fatal...we just need to retry when
      there are jobs available again.
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      fc7f190c
  9. 29 4月, 2016 1 次提交
  10. 16 4月, 2016 1 次提交
  11. 06 4月, 2016 1 次提交
  12. 22 3月, 2016 2 次提交
  13. 18 3月, 2016 1 次提交
  14. 10 3月, 2016 1 次提交
  15. 09 3月, 2016 1 次提交
  16. 08 3月, 2016 7 次提交
  17. 01 3月, 2016 1 次提交
  18. 28 2月, 2016 3 次提交
  19. 25 2月, 2016 2 次提交
    • E
      CVE-2016-0798: avoid memory leak in SRP · 380f18ed
      Emilia Kasper 提交于
      The SRP user database lookup method SRP_VBASE_get_by_user had confusing
      memory management semantics; the returned pointer was sometimes newly
      allocated, and sometimes owned by the callee. The calling code has no
      way of distinguishing these two cases.
      
      Specifically, SRP servers that configure a secret seed to hide valid
      login information are vulnerable to a memory leak: an attacker
      connecting with an invalid username can cause a memory leak of around
      300 bytes per connection.
      
      Servers that do not configure SRP, or configure SRP but do not configure
      a seed are not vulnerable.
      
      In Apache, the seed directive is known as SSLSRPUnknownUserSeed.
      
      To mitigate the memory leak, the seed handling in SRP_VBASE_get_by_user
      is now disabled even if the user has configured a seed.
      
      Applications are advised to migrate to SRP_VBASE_get1_by_user. However,
      note that OpenSSL makes no strong guarantees about the
      indistinguishability of valid and invalid logins. In particular,
      computations are currently not carried out in constant time.
      Reviewed-by: NRich Salz <rsalz@openssl.org>
      380f18ed
    • F
      GH480: Don't break statements with CPP stuff. · b5292f7b
      Flavio Medeiros 提交于
      This is also RT 4137
      Signed-off-by: NRich Salz <rsalz@akamai.com>
      Reviewed-by: NAndy Polyakov <appro@openssl.org>
      b5292f7b
  20. 23 2月, 2016 1 次提交
  21. 17 2月, 2016 1 次提交
  22. 15 2月, 2016 1 次提交
  23. 09 2月, 2016 3 次提交
  24. 06 2月, 2016 1 次提交