Merge pull request #6525 from daverodgman/fix-duplicate-header-2.28
Remove duplicate function prototype - 2.28 backport
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index c580443..94fb020 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,36 +1,19 @@
-Notes:
-* Pull requests cannot be accepted until the PR follows the [contributing guidelines](../CONTRIBUTING.md). In particular, each commit must have at least one `Signed-off-by:` line from the committer to certify that the contribution is made under the terms of the [Developer Certificate of Origin](../dco.txt).
-* This is just a template, so feel free to use/remove the unnecessary things
## Description
-A few sentences describing the overall goals of the pull request's commits.
+
+Please write a few sentences describing the overall goals of the pull request's commits.
-## Status
-**READY/IN DEVELOPMENT/HOLD**
-## Requires Backporting
-When there is a bug fix, it should be backported to all maintained and supported branches.
-Changes do not have to be backported if:
-- This PR is a new feature\enhancement
-- This PR contains changes in the API. If this is true, and there is a need for the fix to be backported, the fix should be handled differently in the legacy branch
+## Gatekeeper checklist
-Yes | NO
-Which branch?
-
-## Migrations
-If there is any API change, what's the incentive and logic for it.
-
-YES | NO
-
-## Additional comments
-Any additional information that could be of interest
-
-## Todos
-- [ ] Tests
-- [ ] Documentation
-- [ ] Changelog updated
-- [ ] Backported
+- [ ] **changelog** provided, or not required
+- [ ] **backport** done, or not required
+- [ ] **tests** provided, or not required
-## Steps to test or reproduce
-Outline the steps to test or reproduce the PR here.
+
+## Notes for the submitter
+
+Please refer to the [contributing guidelines](../CONTRIBUTING.md), especially the
+checklist for PR contributors.
+
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 66fe5f1..d19fe57 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,9 +1,16 @@
Contributing
============
-We gratefully accept bug reports and contributions from the community. There are some requirements we need to fulfill in order to be able to integrate contributions:
+We gratefully accept bug reports and contributions from the community. All PRs are reviewed by the project team / community, and may need some modifications to
+be accepted.
- - As with any open source project, contributions will be reviewed by the project team and community and may need some modifications to be accepted.
- - The contribution should not break API or ABI, unless there is a real justification for that. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release.
+Quick Checklist for PR contributors
+-----------------------------------
+More details on all of these points may be found in the sections below.
+
+- [Sign-off](#license-and-copyright): all commits must be signed off.
+- [Tests](#tests): please ensure the PR includes adequate tests.
+- [Changelog](#documentation): if needed, please provide a changelog entry.
+- [Backports](#long-term-support-branches): provide a backport if needed (it's fine to wait until the main PR is accepted).
Coding Standards
----------------
@@ -25,7 +32,7 @@
The project aims to minimise the impact on users upgrading to newer versions of the library and it should not be necessary for a user to make any changes to their own code to work with a newer version of the library. Unless the user has made an active decision to use newer features, a newer generation of the library or a change has been necessary due to a security issue or other significant software defect, no modifications to their own code should be necessary. To achieve this, API compatibility is maintained between different versions of Mbed TLS on the main development branch and in LTS (Long Term Support) branches, as described in [BRANCHES.md](BRANCHES.md).
-To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change.
+To minimise such disruption to users, where a change to the interface is required, all changes to the ABI or API, even on the main development branch where new features are added, need to be justifiable by either being a significant enhancement, new feature or bug fix which is best resolved by an interface change. If there is an API change, the contribution, if accepted, will be merged only when there will be a major release.
Where changes to an existing interface are necessary, functions in the public interface which need to be changed, are marked as 'deprecated'. This is done with the preprocessor symbols `MBEDTLS_DEPRECATED_WARNING` and `MBEDTLS_DEPRECATED_REMOVED`. Then, a new function with a new name but similar if not identical behaviour to the original function containing the necessary changes should be created alongside the existing deprecated function.
@@ -54,7 +61,7 @@
-----
As mentioned, tests that show the correctness of the feature or bug fix should be added to the pull request, if no such tests exist.
-Mbed TLS includes a comprehensive set of test suites in the `tests/` directory that are dynamically generated to produce the actual test source files (e.g. `test_suite_mpi.c`). These files are generated from a `function file` (e.g. `suites/test_suite_mpi.function`) and a `data file` (e.g. `suites/test_suite_mpi.data`). The function file contains the test functions. The data file contains the test cases, specified as parameters that will be passed to the test function.
+Mbed TLS includes a comprehensive set of test suites in the `tests/` directory that are dynamically generated to produce the actual test source files (e.g. `test_suite_rsa.c`). These files are generated from a `function file` (e.g. `suites/test_suite_rsa.function`) and a `data file` (e.g. `suites/test_suite_rsa.data`). The function file contains the test functions. The data file contains the test cases, specified as parameters that will be passed to the test function.
[A Knowledge Base article describing how to add additional tests is available on the Mbed TLS website](https://mbed-tls.readthedocs.io/en/latest/kb/development/test_suites/).
diff --git a/ChangeLog.d/fix_zeroization.txt b/ChangeLog.d/fix_zeroization.txt
new file mode 100644
index 0000000..ad74d9c
--- /dev/null
+++ b/ChangeLog.d/fix_zeroization.txt
@@ -0,0 +1,3 @@
+Bugfix
+ * Fix possible crash in TLS PRF code, if a failure to allocate memory occurs.
+ Reported by Michael Madsen in #6516.
diff --git a/README.md b/README.md
index a2903db..019fceb 100644
--- a/README.md
+++ b/README.md
@@ -19,7 +19,7 @@
The main Mbed TLS documentation is available via [ReadTheDocs](https://mbed-tls.readthedocs.io/).
-Documentation for the PSA Cryptography API is available [on GitHub](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface).
+Documentation for the PSA Cryptography API is available [on GitHub](https://arm-software.github.io/psa-api/crypto/).
To generate a local copy of the library documentation in HTML format, tailored to your compile-time configuration:
@@ -210,11 +210,11 @@
PSA cryptography API
--------------------
-### PSA API design
+### PSA API
Arm's [Platform Security Architecture (PSA)](https://developer.arm.com/architectures/security-architectures/platform-security-architecture) is a holistic set of threat models, security analyses, hardware and firmware architecture specifications, and an open source firmware reference implementation. PSA provides a recipe, based on industry best practice, that allows security to be consistently designed in, at both a hardware and firmware level.
-The [PSA cryptography API](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.
+The [PSA cryptography API](https://arm-software.github.io/psa-api/crypto/) provides access to a set of cryptographic primitives. It has a dual purpose. First, it can be used in a PSA-compliant platform to build services, such as secure boot, secure storage and secure communication. Second, it can also be used independently of other PSA components on any platform.
The design goals of the PSA cryptography API include:
@@ -226,10 +226,6 @@
Arm welcomes feedback on the design of the API. If you think something could be improved, please open an issue on our Github repository. Alternatively, if you prefer to provide your feedback privately, please email us at [`mbed-crypto@arm.com`](mailto:mbed-crypto@arm.com). All feedback received by email is treated confidentially.
-### PSA API documentation
-
-A browsable copy of the PSA Cryptography API documents is available on the [PSA cryptography interfaces documentation portal](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) in [PDF](https://armmbed.github.io/mbed-crypto/PSA_Cryptography_API_Specification.pdf) and [HTML](https://armmbed.github.io/mbed-crypto/html/index.html) formats.
-
### PSA implementation in Mbed TLS
Mbed TLS includes a reference implementation of the PSA Cryptography API.
diff --git a/library/ssl_tls.c b/library/ssl_tls.c
index 7a4d437..c752d59 100644
--- a/library/ssl_tls.c
+++ b/library/ssl_tls.c
@@ -760,7 +760,9 @@
exit:
mbedtls_md_free( &md_ctx );
- mbedtls_platform_zeroize( tmp, tmp_len );
+ if ( tmp != NULL )
+ mbedtls_platform_zeroize( tmp, tmp_len );
+
mbedtls_platform_zeroize( h_i, sizeof( h_i ) );
mbedtls_free( tmp );
diff --git a/tests/scripts/all.sh b/tests/scripts/all.sh
index a20dd92..21f415b 100755
--- a/tests/scripts/all.sh
+++ b/tests/scripts/all.sh
@@ -1533,12 +1533,15 @@
component_test_full_cmake_clang () {
msg "build: cmake, full config, clang" # ~ 50s
scripts/config.py full
- CC=clang cmake -D CMAKE_BUILD_TYPE:String=Release -D ENABLE_TESTING=On .
+ CC=clang CXX=clang cmake -D CMAKE_BUILD_TYPE:String=Release -D ENABLE_TESTING=On -D TEST_CPP=1 .
make
msg "test: main suites (full config, clang)" # ~ 5s
make test
+ msg "test: cpp_dummy_build (full config, clang)" # ~ 1s
+ programs/test/cpp_dummy_build
+
msg "test: psa_constant_names (full config, clang)" # ~ 1s
tests/scripts/test_psa_constant_names.py
@@ -1756,15 +1759,6 @@
tests/scripts/key-exchanges.pl
}
-component_test_make_cxx () {
- msg "build: Unix make, full, gcc + g++"
- scripts/config.py full
- make TEST_CPP=1 lib programs
-
- msg "test: cpp_dummy_build"
- programs/test/cpp_dummy_build
-}
-
component_test_no_use_psa_crypto_full_cmake_asan() {
# full minus MBEDTLS_USE_PSA_CRYPTO: run the same set of tests as basic-build-test.sh
msg "build: cmake, full config minus MBEDTLS_USE_PSA_CRYPTO, ASan"
@@ -2053,24 +2047,6 @@
make test
}
-# This should be renamed to test and updated once the accelerator ECDSA code is in place and ready to test.
-component_build_psa_accel_alg_ecdsa() {
- # full plus MBEDTLS_PSA_CRYPTO_CONFIG with PSA_WANT_ALG_ECDSA
- # without MBEDTLS_ECDSA_C
- # PSA_WANT_ALG_ECDSA and PSA_WANT_ALG_DETERMINISTIC_ECDSA are already
- # set in include/psa/crypto_config.h
- msg "build: full + MBEDTLS_PSA_CRYPTO_CONFIG + PSA_WANT_ALG_ECDSA without MBEDTLS_ECDSA_C"
- scripts/config.py full
- scripts/config.py set MBEDTLS_PSA_CRYPTO_CONFIG
- scripts/config.py set MBEDTLS_PSA_CRYPTO_DRIVERS
- scripts/config.py unset MBEDTLS_USE_PSA_CRYPTO
- scripts/config.py unset MBEDTLS_ECDSA_C
- scripts/config.py unset MBEDTLS_KEY_EXCHANGE_ECDH_ECDSA_ENABLED
- scripts/config.py unset MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED
- # Need to define the correct symbol and include the test driver header path in order to build with the test driver
- make CC=gcc CFLAGS="$ASAN_CFLAGS -DPSA_CRYPTO_DRIVER_TEST -DMBEDTLS_PSA_ACCEL_ALG_ECDSA -DMBEDTLS_PSA_ACCEL_ALG_DETERMINISTIC_ECDSA -I../tests/include -O2" LDFLAGS="$ASAN_CFLAGS"
-}
-
# This should be renamed to test and updated once the accelerator ECDH code is in place and ready to test.
component_build_psa_accel_alg_ecdh() {
# full plus MBEDTLS_PSA_CRYPTO_CONFIG with PSA_WANT_ALG_ECDH