1. 24 3月, 2023 1 次提交
  2. 10 2月, 2023 4 次提交
  3. 11 7月, 2022 1 次提交
  4. 01 7月, 2022 1 次提交
  5. 25 6月, 2022 1 次提交
  6. 23 6月, 2022 1 次提交
  7. 17 3月, 2022 1 次提交
  8. 08 3月, 2022 1 次提交
  9. 30 1月, 2022 1 次提交
  10. 02 9月, 2021 1 次提交
  11. 10 8月, 2021 1 次提交
  12. 29 6月, 2021 1 次提交
    • H
      兼容MUSL · a18502d4
      HJ 提交于
      a18502d4
  13. 11 3月, 2021 1 次提交
  14. 09 9月, 2020 1 次提交
  15. 01 6月, 2020 1 次提交
  16. 31 5月, 2020 1 次提交
  17. 20 5月, 2020 1 次提交
  18. 31 3月, 2020 1 次提交
  19. 25 3月, 2020 1 次提交
  20. 23 3月, 2020 1 次提交
  21. 20 3月, 2020 1 次提交
  22. 19 3月, 2020 2 次提交
  23. 17 3月, 2020 1 次提交
  24. 14 3月, 2020 1 次提交
    • B
      Code to thread-safety in ChangeCipherState · 44bad9cb
      Benjamin Kaduk 提交于
      The server-side ChangeCipherState processing stores the new cipher
      in the SSL_SESSION object, so that the new state can be used if
      this session gets resumed.  However, writing to the session is only
      thread-safe for initial handshakes, as at other times the session
      object may be in a shared cache and in use by another thread at the
      same time.  Reflect this invariant in the code by only writing to
      s->session->cipher when it is currently NULL (we do not cache sessions
      with no cipher).  The code prior to this change would never actually
      change the (non-NULL) cipher value in a session object, since our
      server enforces that (pre-TLS-1.3) resumptions use the exact same
      cipher as the initial connection, and non-abbreviated renegotiations
      have produced a new session object before we get to this point.
      Regardless, include logic to detect such a condition and abort the
      handshake if it occurs, to avoid any risk of inadvertently using
      the wrong cipher on a connection.
      Reviewed-by: NTomas Mraz <tmraz@fedoraproject.org>
      (Merged from https://github.com/openssl/openssl/pull/10943)
      
      (cherry picked from commit 2e3ec2e1578977fca830a47fd7f521e290540e6d)
      44bad9cb
  25. 11 3月, 2020 1 次提交
  26. 06 3月, 2020 2 次提交
  27. 05 3月, 2020 1 次提交
  28. 28 2月, 2020 1 次提交
  29. 27 2月, 2020 1 次提交
  30. 21 2月, 2020 2 次提交
  31. 17 2月, 2020 1 次提交
  32. 15 2月, 2020 1 次提交
  33. 12 2月, 2020 1 次提交
  34. 07 2月, 2020 1 次提交