Skip to content
  1. Aug 08, 2019
  2. Aug 06, 2019
  3. Aug 05, 2019
    • Matt Caswell's avatar
      Fix SSL_MODE_RELEASE_BUFFERS functionality · f2bb79a7
      Matt Caswell authored
      
      
      At some point in the past do_ssl3_write() used to return the number of
      bytes written, or a value <= 0 on error. It now just returns a success/
      error code and writes the number of bytes written to |tmpwrit|.
      
      The SSL_MODE_RELEASE_BUFFERS code was still looking at the return code
      for the number of bytes written rather than |tmpwrit|. This has the effect
      that the buffers are not released when they are supposed to be.
      
      Fixes #9490
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/9505)
      
      (cherry picked from commit 8bbf63e48f27c5edaa03e6d87d969c9b6a207f3c)
      f2bb79a7
  4. Aug 01, 2019
  5. Jul 31, 2019
  6. Jul 30, 2019
    • Bernd Edlinger's avatar
      Use OPENSSL_strlcpy instead of strncpy in e_afalg.c · 74f4cc02
      Bernd Edlinger authored
      
      
      This avoids a spurious gcc warning:
      ./config enable-asan --strict-warnings
      =>
      In function 'afalg_create_sk',
          inlined from 'afalg_cipher_init' at engines/e_afalg.c:545:11:
      engines/e_afalg.c:376:5: error: '__builtin_strncpy' output may be
          truncated copying 63 bytes from a string of length 63 [-Werror=stringop-truncation]
        376 |     strncpy((char *) sa.salg_name, ciphername, ALG_MAX_SALG_NAME);
            |     ^~~~~~~
      
      [extended tests]
      
      Reviewed-by: default avatarPaul Dale <paul.dale@oracle.com>
      (Merged from https://github.com/openssl/openssl/pull/9478)
      
      (cherry picked from commit 62cc845fc955c8d4de7b703f57bfd8e5854f00f4)
      74f4cc02
  7. Jul 28, 2019
  8. Jul 25, 2019
    • David Benjamin's avatar
      Don't generate an unnecessary Diffie-Hellman key in TLS 1.3 clients. · e4a282fe
      David Benjamin authored
      
      
      tls_parse_stoc_key_share was generating a new EVP_PKEY public/private
      keypair and then overrides it with the server public key, so the
      generation was a waste anyway. Instead, it should create a
      parameters-only EVP_PKEY.
      
      (This is a consequence of OpenSSL using the same type for empty key,
      empty key with key type, empty key with key type + parameters, public
      key, and private key. As a result, it's easy to mistakenly mix such
      things up, as happened here.)
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      Reviewed-by: default avatarKurt Roeckx <kurt@roeckx.be>
      (Merged from https://github.com/openssl/openssl/pull/9445)
      
      (cherry picked from commit 166c0b98fd6e8b1bb341397642527a9396468f6c)
      e4a282fe
    • Richard Levitte's avatar
      Fix default installation paths on mingw · 54aa9d51
      Richard Levitte authored
      
      
      Mingw config targets assumed that resulting programs and libraries are
      installed in a Unix-like environment and the default installation
      prefix was therefore set to '/usr/local'.
      
      However, mingw programs are installed in a Windows environment, and
      the installation directories should therefore have Windows defaults,
      i.e. the same kind of defaults as the VC config targets.
      
      A difficulty is, however, that a "cross compiled" build can't figure
      out the system defaults from environment the same way it's done when
      building "natively", so we have to fall back to hard coded defaults in
      that case.
      
      Tests can still be performed when cross compiled on a non-Windows
      platform, since all tests only depend on the source and build
      directory, and otherwise relies on normal local paths.
      
      CVE-2019-1552
      
      Reviewed-by: default avatarMatt Caswell <matt@openssl.org>
      (Merged from https://github.com/openssl/openssl/pull/9400)
      54aa9d51
  9. Jul 23, 2019
  10. Jul 24, 2019
  11. Jul 23, 2019
  12. Jul 21, 2019
  13. Jul 19, 2019
  14. Jul 18, 2019
  15. Jul 17, 2019
  16. Jul 16, 2019
  17. Jul 15, 2019
  18. Jul 11, 2019
  19. Jul 08, 2019
  20. Jul 07, 2019