fortanix · Taowyoo · Jan 2, 2025 · Dec 23, 2024 · Jan 25, 2019 · Mar 10, 2020
diff --git a/Cargo.lock b/Cargo.lock
diff --git a/mbedtls-sys/Cargo.toml b/mbedtls-sys/Cargo.toml
@@ -1,6 +1,6 @@
 [package]
 name = "mbedtls-sys-auto"
-version = "2.28.7"
+version = "2.28.9"
 authors = ["Jethro Beekman <[email protected]>"]
 build = "build/build.rs"
 license = "Apache-2.0 OR GPL-2.0-or-later"
@@ -15,8 +15,8 @@ links = "mbedtls"
 
 [package.metadata.mbedtls]
 git = "https://github.com/Mbed-TLS/mbedtls.git"
-version = "2.28.7"
-rev = "555f84735aecdbd76a566cf087ec8425dfb0c8ab"
+version = "2.28.9"
+rev = "5e146adef63b326b04282252639bebc2730939c6"
 
 [lib]
 name = "mbedtls_sys"

diff --git a/mbedtls-sys/vendor/.gitignore b/mbedtls-sys/vendor/.gitignore
@@ -2,6 +2,9 @@
 seedfile
 # MBEDTLS_PSA_INJECT_ENTROPY seed file created by the test framework
 00000000ffffff52.psa_its
+# Log files created by all.sh to reduce the logs in case a component runs
+# successfully
+quiet-make.*
 
 # CMake build artifacts:
 CMakeCache.txt

diff --git a/mbedtls-sys/vendor/3rdparty/CMakeLists.txt b/mbedtls-sys/vendor/3rdparty/CMakeLists.txt
@@ -4,11 +4,7 @@ list (APPEND thirdparty_inc_public)
 list (APPEND thirdparty_inc)
 list (APPEND thirdparty_def)
 
-execute_process(COMMAND ${MBEDTLS_PYTHON_EXECUTABLE} ${CMAKE_CURRENT_SOURCE_DIR}/../scripts/config.py -f ${CMAKE_CURRENT_SOURCE_DIR}/../include/mbedtls/config.h get MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED RESULT_VARIABLE result)
-
-if(${result} EQUAL 0)
-    add_subdirectory(everest)
-endif()
+add_subdirectory(everest)
 
 set(thirdparty_src ${thirdparty_src} PARENT_SCOPE)
 set(thirdparty_lib ${thirdparty_lib} PARENT_SCOPE)

diff --git a/mbedtls-sys/vendor/BRANCHES.md b/mbedtls-sys/vendor/BRANCHES.md
@@ -1,25 +1,33 @@
 # Maintained branches
 
-At any point in time, we have a number of maintained branches consisting of:
+At any point in time, we have a number of maintained branches, currently consisting of:
 
-- The [`master`](https://github.com/Mbed-TLS/mbedtls/tree/master) branch:
+- The [`main`](https://github.com/Mbed-TLS/mbedtls/tree/main) branch:
   this always contains the latest release, including all publicly available
   security fixes.
 - The [`development`](https://github.com/Mbed-TLS/mbedtls/tree/development) branch:
-  this is where new features land,
-  as well as bug fixes and security fixes.
-- One or more long-time support (LTS) branches:
-  these only get bug fixes and security fixes.
+  this is where the next major version of Mbed TLS (version 4.0) is being
+  prepared. It has API changes that make it incompatible with Mbed TLS 3.x,
+  as well as all the new features and bug fixes and security fixes.
+- One or more long-time support (LTS) branches: these only get bug fixes and
+  security fixes. Currently, the supported LTS branches are:
+- [`mbedtls-2.28`](https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-2.28).
+- [`mbedtls-3.6`](https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6).
+
+We retain a number of historical branches, whose names are prefixed by `archive/`,
+such as [`archive/mbedtls-2.7`](https://github.com/Mbed-TLS/mbedtls/tree/archive/mbedtls-2.7).
+These branches will not receive any changes or updates.
 
 We use [Semantic Versioning](https://semver.org/). In particular, we maintain
-API compatibility in the `master` branch between major version changes. We
-also maintain ABI compatibility within LTS branches; see the next section for
-details.
+API compatibility in the `main` branch across minor version changes (e.g.
+the API of 3.(x+1) is backward compatible with 3.x). We only break API
+compatibility on major version changes (e.g. from 3.x to 4.0). We also maintain
+ABI compatibility within LTS branches; see the next section for details.
 
-Every major version will become an LTS branch when the next major version is
-released. We may occasionally create LTS branches from other releases at our
-discretion.
-When a new LTS branch is created, it usually remains supported for three years.
+We will make regular LTS releases on an 18-month cycle, each of which will have
+a 3 year support lifetime. On this basis, 3.6 LTS (released March 2024) will be
+supported until March 2027. The next LTS release will be a 4.x release, which is
+planned for September 2025.
 
 ## Backwards Compatibility for application code
 
@@ -30,30 +38,33 @@ modification with any later release x.y'.z' with the same major version
 number, and your code will still build, be secure, and work.
 
 Note that this guarantee only applies if you either use the default
-compile-time configuration (`mbedtls/config.h`) or the same modified
+compile-time configuration (`mbedtls/mbedtls_config.h`) or the same modified
 compile-time configuration. Changing compile-time configuration options can
 result in an incompatible API or ABI, although features will generally not
 affect unrelated features (for example, enabling or disabling a
 cryptographic algorithm does not break code that does not use that
 algorithm).
 
-There are rare exceptions: code that was relying on something that became
-insecure in the meantime (for example, crypto that was found to be weak) may
-need to be changed. In case security comes in conflict with backwards
-compatibility, we will put security first, but always attempt to provide a
-compatibility option.
-
-For the LTS branches, additionally we try very hard to also maintain ABI
-compatibility (same definition as API except with re-linking instead of
-re-compiling) and to avoid any increase in code size or RAM usage, or in the
-minimum version of tools needed to build the code. The only exception, as
-before, is in case those goals would conflict with fixing a security issue, we
-will put security first but provide a compatibility option. (So far we never
-had to break ABI compatibility in an LTS branch, but we occasionally had to
-increase code size for a security fix.)
-
-For contributors, see the [Backwards Compatibility section of
-CONTRIBUTING](CONTRIBUTING.md#backwards-compatibility).
+Note that new releases of Mbed TLS may extend the API. Here are some
+examples of changes that are common in minor releases of Mbed TLS, and are
+not considered API compatibility breaks:
+
+* Adding or reordering fields in a structure or union.
+* Removing a field from a structure, unless the field is documented as public.
+* Adding items to an enum.
+* Returning an error code that was not previously documented for a function
+  when a new error condition arises.
+* Changing which error code is returned in a case where multiple error
+  conditions apply.
+* Changing the behavior of a function from failing to succeeding, when the
+  change is a reasonable extension of the current behavior, i.e. the
+  addition of a new feature.
+
+There are rare exceptions where we break API compatibility: code that was
+relying on something that became insecure in the meantime (for example,
+crypto that was found to be weak) may need to be changed. In case security
+comes in conflict with backwards compatibility, we will put security first,
+but always attempt to provide a compatibility option.
 
 ## Backward compatibility for the key store
 
@@ -68,14 +79,37 @@ Mbed TLS 3.x can also read keys written by Mbed TLS 2.25.0 through 2.28.x
 LTS, but future major version upgrades (for example from 2.28.x/3.x to 4.y)
 may require the use of an upgrade tool.
 
+Note that this guarantee does not currently fully extend to drivers, which
+are an experimental feature. We intend to maintain compatibility with the
+basic use of drivers from Mbed TLS 2.28.0 onwards, even if driver APIs
+change. However, for more experimental parts of the driver interface, such
+as the use of driver state, we do not yet guarantee backward compatibility.
+
+## Long-time support branches
+
+For the LTS branches, additionally we try very hard to also maintain ABI
+compatibility (same definition as API except with re-linking instead of
+re-compiling) and to avoid any increase in code size or RAM usage, or in the
+minimum version of tools needed to build the code. The only exception, as
+before, is in case those goals would conflict with fixing a security issue, we
+will put security first but provide a compatibility option. (So far we never
+had to break ABI compatibility in an LTS branch, but we occasionally had to
+increase code size for a security fix.)
+
+For contributors, see the [Backwards Compatibility section of
+CONTRIBUTING](CONTRIBUTING.md#backwards-compatibility).
+
 ## Current Branches
 
 The following branches are currently maintained:
 
-- [master](https://github.com/Mbed-TLS/mbedtls/tree/master)
+- [main](https://github.com/Mbed-TLS/mbedtls/tree/main)
 - [`development`](https://github.com/Mbed-TLS/mbedtls/)
+- [`mbedtls-3.6`](https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-3.6)
+ maintained until March 2027, see
+  <https://github.com/Mbed-TLS/mbedtls/releases/tag/v3.6.1>.
 - [`mbedtls-2.28`](https://github.com/Mbed-TLS/mbedtls/tree/mbedtls-2.28)
- maintained until at least the end of 2024, see
-  <https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.7>.
+ maintained until the end of 2024, see
+  <https://github.com/Mbed-TLS/mbedtls/releases/tag/v2.28.9>.
 
 Users are urged to always use the latest version of a maintained branch.
diff --git a/mbedtls-sys/vendor/BUGS.md b/mbedtls-sys/vendor/BUGS.md
@@ -7,7 +7,7 @@ Known issues in Mbed TLS are [tracked on GitHub](https://github.com/Mbed-TLS/mbe
 If you think you've found a bug in Mbed TLS, please follow these steps:
 
 1. Make sure you're using the latest version of a
-   [maintained branch](BRANCHES.md): `master`, `development`,
+   [maintained branch](BRANCHES.md): `main`, `development`,
    or a long-time support branch.
 2. Check [GitHub](https://github.com/Mbed-TLS/mbedtls/issues) to see if
    your issue has already been reported. If not, …

diff --git a/mbedtls-sys/vendor/CMakeLists.txt b/mbedtls-sys/vendor/CMakeLists.txt
@@ -39,6 +39,8 @@ else()
     project("Mbed TLS" C)
 endif()
 
+include(GNUInstallDirs)
+
 # Set the project root directory.
 set(MBEDTLS_DIR ${CMAKE_CURRENT_SOURCE_DIR})
 
@@ -259,8 +261,7 @@ if(CMAKE_BUILD_TYPE STREQUAL "Coverage")
 endif(CMAKE_BUILD_TYPE STREQUAL "Coverage")
 
 if(LIB_INSTALL_DIR)
-else()
-    set(LIB_INSTALL_DIR lib)
+    set(CMAKE_INSTALL_LIBDIR "${LIB_INSTALL_DIR}")
 endif()
 
 if(ENABLE_ZLIB_SUPPORT)
@@ -278,6 +279,8 @@ list(APPEND libs ${thirdparty_lib})
 
 add_subdirectory(library)
 
+add_subdirectory(pkgconfig)
+
 #
 # The C files in tests/src directory contain test code shared among test suites
 # and programs. This shared test code is compiled and linked to test suites and

diff --git a/mbedtls-sys/vendor/CONTRIBUTING.md b/mbedtls-sys/vendor/CONTRIBUTING.md
@@ -86,7 +86,7 @@ License and Copyright
 
 Unless specifically indicated otherwise in a file, Mbed TLS files are provided under a dual [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) OR [GPL-2.0-or-later](https://spdx.org/licenses/GPL-2.0-or-later.html) license. See the [LICENSE](LICENSE) file for the full text of these licenses. This means that users may choose which of these licenses they take the code under.
 
-Contributors must accept that their contributions are made under both the Apache-2.0 AND [GPL-2.0-or-later](https://spdx.org/licenses/GPL-2.0-or-later.html) licenses. This enables LTS (Long Term Support) branches of the software to be provided under either the Apache-2.0 or GPL-2.0-or-later licenses.
+Contributors must accept that their contributions are made under both the Apache-2.0 AND [GPL-2.0-or-later](https://spdx.org/licenses/GPL-2.0-or-later.html) licenses.
 
 All new files should include the standard SPDX license identifier where possible, i.e. "SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later".
 

diff --git a/mbedtls-sys/vendor/ChangeLog b/mbedtls-sys/vendor/ChangeLog
@@ -1,5 +1,81 @@
 Mbed TLS ChangeLog (Sorted per branch, date)
 
+= Mbed TLS 2.28.9 branch released 2024-08-30
+
+Security
+   * Unlike previously documented, enabling MBEDTLS_PSA_HMAC_DRBG_MD_TYPE does
+     not cause the PSA subsystem to use HMAC_DRBG: it uses HMAC_DRBG only when
+     MBEDTLS_PSA_CRYPTO_EXTERNAL_RNG and MBEDTLS_CTR_DRBG_C are disabled.
+     CVE-2024-45157
+
+Bugfix
+   * Fix the build in some configurations when check_config.h is not included.
+     Fix #9152.
+   * Fix issue of redefinition warning messages for _GNU_SOURCE in
+     entropy_poll.c and sha_256.c. There was a build warning during
+     building for linux platform.
+     Resolves #9026
+   * Fix error handling when creating a key in a dynamic secure element
+     (feature enabled by MBEDTLS_PSA_CRYPTO_SE_C). In a low memory condition,
+     the creation could return PSA_SUCCESS but using or destroying the key
+     would not work. Fixes #8537.
+   * Fix a memory leak that could occur when failing to process an RSA
+     key through some PSA functions due to low memory conditions.
+   * Document and enforce the limitation of mbedtls_psa_register_se_key()
+     to persistent keys. Resolves #9253.
+
+= Mbed TLS 2.28.8 branch released 2024-03-28
+
+Features
+   * AES-NI is now supported in Windows builds with clang and clang-cl.
+     Resolves #8372.
+   * Add pc files for pkg-config, e.g.:
+     pkg-config --cflags --libs (mbedtls|mbedcrypto|mbedx509)
+
+Security
+   * Passing buffers that are stored in untrusted memory as arguments
+     to PSA functions is now secure by default.
+     The PSA core now protects against modification of inputs or exposure
+     of intermediate outputs during operations. This is currently implemented
+     by copying buffers.
+     This feature increases code size and memory usage. If buffers passed to
+     PSA functions are owned exclusively by the PSA core for the duration of
+     the function call (i.e. no buffer parameters are in shared memory),
+     copying may be disabled by setting MBEDTLS_PSA_ASSUME_EXCLUSIVE_BUFFERS.
+     Note that setting this option will cause input-output buffer overlap to
+     be only partially supported (#3266).
+     Fixes CVE-2024-28960.
+
+Bugfix
+   * Fix the build with CMake when Everest is enabled through
+     a user configuration file or the compiler command line. Fixes #8165.
+   * Fix an inconsistency between implementations and usages of `__cpuid`,
+     which mainly causes failures when building Windows target using
+     mingw or clang. Fixes #8334 & #8332.
+   * Correct initial capacities for key derivation algorithms: TLS12_PRF,
+     TLS12_PSK_TO_MS.
+   * Fix mbedtls_pk_get_bitlen() for RSA keys whose size is not a
+     multiple of 8. Fixes #868.
+   * Avoid segmentation fault caused by releasing not initialized
+     entropy resource in gen_key example. Fixes #8809.
+   * Fix missing bitflags in SSL session serialization headers. Their absence
+     allowed SSL sessions saved in one configuration to be loaded in a
+     different, incompatible configuration.
+   * Fix the restoration of the ALPN when loading serialized connection with
+     the mbedtls_ssl_context_load() API.
+   * Fully support arbitrary overlap between inputs and outputs of PSA
+     functions. Note that overlap is still only partially supported when
+     MBEDTLS_PSA_ASSUME_EXCLUSIVE_BUFFERS is set (#3266).
+
+Changes
+   * Use heap memory to allocate DER encoded public/private key.
+     This reduces stack usage significantly for writing a public/private
+     key to a PEM string.
+   * cmake: Use GnuInstallDirs to customize install directories
+     Replace custom LIB_INSTALL_DIR variable with standard CMAKE_INSTALL_LIBDIR
+     variable. For backward compatibility, set CMAKE_INSTALL_LIBDIR if
+     LIB_INSTALL_DIR is set.
+
 = Mbed TLS 2.28.7 branch released 2024-01-26
 
 Security

diff --git a/mbedtls-sys/vendor/README.md b/mbedtls-sys/vendor/README.md
@@ -190,7 +190,7 @@ For machines with a Unix shell and OpenSSL (and optionally GnuTLS) installed, ad
 -   `tests/scripts/depends.py` test builds in configurations with a single curve, key exchange, hash, cipher, or pkalg on.
 -   `tests/scripts/all.sh` runs a combination of the above tests, plus some more, with various build options (such as ASan, full `config.h`, etc).
 
-Instead of manually installing the required versions of all tools required for testing, it is possible to use the Docker images from our CI systems, as explained in [our testing infrastructure repository](https://github.com/Mbed-TLS/mbedtls-test/blob/master/README.md#quick-start).
+Instead of manually installing the required versions of all tools required for testing, it is possible to use the Docker images from our CI systems, as explained in [our testing infrastructure repository](https://github.com/Mbed-TLS/mbedtls-test/blob/main/README.md#quick-start).
 
 Porting Mbed TLS
 ----------------