auto commit by copy to link target

• Files Changed
• Browse Source

-  Workaround for building with gcc-11 boo#1181876

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

  mbedtls-4237.patch

• Files Changed
• Browse Source

- Update to 2.26.0:
  * * This release of Mbed TLS provides bug fixes, minor enhancements and new
  features. This release includes fixes for security issues.
  * see https://github.com/ARMmbed/mbedtls/releases/tag/v2.26.0
- Fix build with patch from https://github.com/ARMmbed/mbedtls/pull/4237

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- Fix build for Leap targets
- Use upstream tarball name

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- update to 2.25.0:
  * This release of Mbed TLS provides bug fixes, minor enhancements and new
  features. This release includes fixes for security issues. 
  * see https://github.com/ARMmbed/mbedtls/releases/tag/v2.25.0
  * The functions mbedtls_cipher_auth_encrypt() and
  mbedtls_cipher_auth_decrypt() would write past the minimum documented size
  of the output buffer when used with NIST_KW. As a result, code using those
  functions as documented with NIST_KW could have a buffer overwrite of up to
  15 bytes, with consequences ranging up to arbitrary code execution
  depending on the location of the output buffer.
  * Limit the size of calculations performed by mbedtls_mpi_exp_mod to
  MBEDTLS_MPI_MAX_SIZE to prevent a potential denial of service when generating
  Diffie-Hellman key pairs. Credit to OSS-Fuzz.
  
  * A failure of the random generator was ignored in mbedtls_mpi_fill_random(),
  which is how most uses of randomization in asymmetric cryptography (including
  key generation, intermediate value randomization and blinding) are implemented.
  This could cause failures or the silent use of non-random values. A random
  generator can fail if it needs reseeding and cannot not obtain entropy, or due
  to an internal failure (which, for Mbed TLS's own CTR_DRBG or HMAC_DRBG, can
  only happen due to a misconfiguration).
  
  * Fix a compliance issue whereby we were not checking the tag on the algorithm
  parameters (only the size) when comparing the signature in the description part
  of the cert to the real signature. This meant that a NULL algorithm parameters
  entry would look identical to an array of REAL (size zero) to the library and
  thus the certificate would be considered valid. However, if the parameters do
  not match in any way then the certificate should be considered invalid, and
  indeed OpenSSL marks these certs as invalid when mbedtls did not. Many thanks
  to guidovranken who found this issue via differential fuzzing and reported it

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- update to 2.24.0:
  * see https://github.com/ARMmbed/mbedtls/releases/tag/v2.24.0
  * Fix a vulnerability in the verification of X.509 certificates when matching
  the expected common name (the cn argument of mbedtls_x509_crt_verify())
  with the actual certificate name: when the subjecAltName extension is
  present, the expected name was compared to any name in that extension
  regardless of its type. This means that an attacker could for example
  impersonate a 4-bytes or 16-byte domain by getting a certificate for the
  corresponding IPv4 or IPv6 (this would require the attacker to control that
  IP address, though). Similar attacks using other subjectAltName name types
  might be possible.
  * When checking X.509 CRLs, a certificate was only considered as revoked if
  its revocationDate was in the past according to the local clock if
  available. In particular, on builds without MBEDTLS_HAVE_TIME_DATE,
  certificates were never considered as revoked. On builds with
  MBEDTLS_HAVE_TIME_DATE, an attacker able to control the local clock (for
  example, an untrusted OS attacking a secure enclave) could prevent
  revocation of certificates via CRLs. Fixed by no longer checking the
  revocationDate field, in accordance with RFC 5280. Reported by yuemonangong
  in #3340. Reported independently and fixed by Raoul Strackx and Jethro
  * In (D)TLS record decryption, when using a CBC ciphersuites without the
  Encrypt-then-Mac extension, use constant code flow memory access patterns
  to extract and check the MAC. This is an improvement to the existing
  countermeasure against Lucky 13 attacks. The previous countermeasure was
  effective against network-based attackers, but less so against local
  attackers. The new countermeasure defends against local attackers, even if
  they have access to fine-grained measurements. In particular, this fixes a
  local Lucky 13 cache attack found and reported by Tuba Yavuz, Farhaan
  Fowze, Ken (Yihan) Bai, Grant Hernandez, and Kevin Butler (University of
  Florida) and Dave Tian (Purdue University).

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- Add workaround for failing builds (Python not found) due to
  https://gitlab.kitware.com/cmake/cmake/-/issues/21168

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- Do not run testsuite in parallel - its not reliable

• Files Changed
• Browse Source

- update to 2.23.0:
  a lot of changes see https://github.com/ARMmbed/mbedtls/releases/tag/v2.23.0
  * Fix a side channel vulnerability in modular exponentiation that could reveal an RSA private key used in a secure enclave. Noticed by Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim and Hyesoon Kim (Georgia Institute of Technology); and Marcus Peinado (Microsoft Research). Reported by Raoul Strackx (Fortanix) in #3394.
  * Fix side channel in mbedtls_ecp_check_pub_priv() and mbedtls_pk_parse_key() / mbedtls_pk_parse_keyfile() (when loading a private key that didn't include the uncompressed public key), as well as mbedtls_ecp_mul() / mbedtls_ecp_mul_restartable() when called with a NULL f_rng argument. An attacker with access to precise enough timing and memory access information (typically an untrusted operating system attacking a secure enclave) could fully recover the ECC private key. Found and reported by Alejandro Cabrera Aldaya and Billy Brumley.
  * Fix issue in Lucky 13 counter-measure that could make it ineffective when hardware accelerators were used (using one of the MBEDTLS_SHAxxx_ALT macros). This would cause the original Lucky 13 attack to be possible in those configurations, allowing an active network attacker to recover plaintext after repeated timing measurements under some conditions. Reported and fix suggested by Luc Perneel in #3246.

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

- Update to version 2.16.5:
  * Security improvements and bugfixes

• Files Changed
• Browse Source

auto commit by copy to link target

• Files Changed
• Browse Source

• Files Changed
• Browse Source