1. 13 11月, 2016 1 次提交
  2. 02 11月, 2016 1 次提交
  3. 19 10月, 2016 1 次提交
  4. 18 10月, 2016 1 次提交
  5. 15 10月, 2016 1 次提交
  6. 01 10月, 2016 1 次提交
  7. 29 9月, 2016 1 次提交
  8. 19 9月, 2016 1 次提交
  9. 16 9月, 2016 3 次提交
  10. 13 9月, 2016 1 次提交
  11. 20 8月, 2016 2 次提交
  12. 19 8月, 2016 1 次提交
  13. 18 8月, 2016 3 次提交
  14. 04 8月, 2016 1 次提交
  15. 27 7月, 2016 1 次提交
  16. 19 7月, 2016 2 次提交
  17. 08 7月, 2016 1 次提交
  18. 25 6月, 2016 1 次提交
  19. 22 6月, 2016 1 次提交
  20. 19 6月, 2016 1 次提交
  21. 13 6月, 2016 1 次提交
  22. 12 6月, 2016 2 次提交
  23. 10 6月, 2016 1 次提交
  24. 27 5月, 2016 2 次提交
    • M
      Fix intermittent windows failures in TLSProxy tests · cb2e10f2
      Matt Caswell 提交于
      When closing down the socket in s_client Windows will close it immediately
      even if there is data in the write buffer still waiting to be sent. This
      was causing tests to fail in Msys/Mingw builds because TLSProxy doesn't see
      the final CloseNotify.
      
      I have experimented with various ways of doing this "properly" (e.g.
      shutting down the socket before closing, setting SO_LINGER etc). I can't
      seem to find the "magic" formula that will make Windows do this. Inserting
      a short 50ms sleep seems to do the trick...but its not very "nice" so I've
      inserted a TODO on this item. Perhaps someone else will have better luck
      in figuring this out.
      
      RT#4255
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      cb2e10f2
    • 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
  25. 18 5月, 2016 3 次提交
  26. 17 5月, 2016 2 次提交
  27. 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
  28. 21 4月, 2016 1 次提交
  29. 11 4月, 2016 1 次提交