1. 23 2月, 2019 1 次提交
  2. 22 2月, 2019 1 次提交
  3. 21 2月, 2019 6 次提交
  4. 20 2月, 2019 1 次提交
  5. 19 2月, 2019 4 次提交
  6. 18 2月, 2019 4 次提交
  7. 15 2月, 2019 4 次提交
    • R
      Mark generated functions unused (applies to safestack, lhash, sparse_array) · ed48d203
      Richard Levitte 提交于
      safestack.h, lhash.h and sparse_array.h all define macros to generate
      a full API for the containers as static inline functions.  This
      potentially generates unused code, which some compilers may complain
      about.
      
      We therefore need to mark those generated functions as unused, so the
      compiler knows that we know, and stops complaining about it.
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8246)
      
      (cherry picked from commit 48fe4ce104df060dd5d2b4188a56eb554d94d819)
      ed48d203
    • M
      Use order not degree to calculate a buffer size in ecdsatest · 1b25dc0c
      Matt Caswell 提交于
      Otherwise this can result in an incorrect calculation of the maximum
      encoded integer length, meaning an insufficient buffer size is allocated.
      
      Thanks to Billy Brumley for helping to track this down.
      
      Fixes #8209
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      Reviewed-by: NPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/8237)
      
      (cherry picked from commit 9fc8f18f59f4a4c853466dca64a23b8af681bf1c)
      1b25dc0c
    • M
      Fix -verify_return_error in s_client · 9c931841
      Matt Caswell 提交于
      The "verify_return_error" option in s_client is documented as:
      
       Return verification errors instead of continuing. This will typically
       abort the handshake with a fatal error.
      
      In practice this option was ignored unless also accompanied with the
      "-verify" option. It's unclear what the original intention was. One fix
      could have been to change the documentation to match the actual behaviour.
      However it seems unecessarily complex and unexpected that you should need
      to have both options. Instead the fix implemented here is make the option
      match the documentation so that "-verify" is not also required.
      
      Note that s_server has a similar option where "-verify" (or "-Verify") is
      still required. This makes more sense because those options additionally
      request a certificate from the client. Without a certificate there is no
      possibility of a verification failing, and so "-verify_return_error" doing
      nothing seems ok.
      
      Fixes #8079
      Reviewed-by: NNicola Tuveri <nic.tuv@gmail.com>
      (Merged from https://github.com/openssl/openssl/pull/8080)
      
      (cherry picked from commit 78021171dbcb05ddab1b5daffbfc62504ea709a4)
      9c931841
    • M
      Don't signal SSL_CB_HANDSHAKE_START for TLSv1.3 post-handshake messages · 37857e9b
      Matt Caswell 提交于
      The original 1.1.1 design was to use SSL_CB_HANDSHAKE_START and
      SSL_CB_HANDSHAKE_DONE to signal start/end of a post-handshake message
      exchange in TLSv1.3. Unfortunately experience has shown that this confuses
      some applications who mistake it for a TLSv1.2 renegotiation. This means
      that KeyUpdate messages are not handled properly.
      
      This commit removes the use of SSL_CB_HANDSHAKE_START and
      SSL_CB_HANDSHAKE_DONE to signal the start/end of a post-handshake
      message exchange. Individual post-handshake messages are still signalled in
      the normal way.
      
      This is a potentially breaking change if there are any applications already
      written that expect to see these TLSv1.3 events. However, without it,
      KeyUpdate is not currently usable for many applications.
      
      Fixes #8069
      Reviewed-by: NRichard Levitte <levitte@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/8096)
      
      (cherry picked from commit 4af5836b55442f31795eff6c8c81ea7a1b8cf94b)
      37857e9b
  8. 14 2月, 2019 3 次提交
  9. 13 2月, 2019 2 次提交
  10. 11 2月, 2019 4 次提交
  11. 08 2月, 2019 4 次提交
  12. 07 2月, 2019 1 次提交
  13. 05 2月, 2019 4 次提交
  14. 02 2月, 2019 1 次提交