From 457b58c439977cea60ab2f39a4843de74bb514f8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Manuel=20P=C3=A9gouri=C3=A9-Gonnard?= Date: Wed, 25 Mar 2020 12:41:29 +0100 Subject: [PATCH 1/6] Fix leakage of projective coordinates in ECC MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Fix side channel in ECC code that allowed an adversary with access to precise enough timing and memory access information (typically an untrusted operating system attacking a secure enclave) to fully recover an ECDSA private key. Found and reported by Alejandro Cabrera Aldaya, Billy Brumley and Cesar Pereida Garcia. CVE-2020-10932 See the comments in the code for how an attack would go. For ECDSA, leaking a few bits of the scalar over several signatures translates to full private key recovery using a lattice attack. Signed-off-by: Manuel Pégourié-Gonnard --- library/ecp.c | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) diff --git a/library/ecp.c b/library/ecp.c index 19942e52e..3a9e50125 100644 --- a/library/ecp.c +++ b/library/ecp.c @@ -2016,6 +2016,20 @@ static int ecp_mul_comb_after_precomp( const mbedtls_ecp_group *grp, final_norm: #endif + /* + * Knowledge of the jacobian coordinates may leak the last few bits of the + * scalar [1], and since our MPI implementation isn't constant-flow, + * inversion (used for coordinate normalization) may leak the full value + * of its input via side-channels [2]. + * + * [1] https://eprint.iacr.org/2003/191 + * [2] https://eprint.iacr.org/2020/055 + * + * Avoid the leak by randomizing coordinates before we normalize them. + */ + if( f_rng != 0 ) + MBEDTLS_MPI_CHK( ecp_randomize_jac( grp, RR, f_rng, p_rng ) ); + MBEDTLS_ECP_BUDGET( MBEDTLS_ECP_OPS_INV ); MBEDTLS_MPI_CHK( ecp_normalize_jac( grp, RR ) ); @@ -2388,6 +2402,20 @@ static int ecp_mul_mxz( mbedtls_ecp_group *grp, mbedtls_ecp_point *R, MBEDTLS_MPI_CHK( mbedtls_mpi_safe_cond_swap( &R->Z, &RP.Z, b ) ); } + /* + * Knowledge of the projective coordinates may leak the last few bits of the + * scalar [1], and since our MPI implementation isn't constant-flow, + * inversion (used for coordinate normalization) may leak the full value + * of its input via side-channels [2]. + * + * [1] https://eprint.iacr.org/2003/191 + * [2] https://eprint.iacr.org/2020/055 + * + * Avoid the leak by randomizing coordinates before we normalize them. + */ + if( f_rng != NULL ) + MBEDTLS_MPI_CHK( ecp_randomize_mxz( grp, R, f_rng, p_rng ) ); + MBEDTLS_MPI_CHK( ecp_normalize_mxz( grp, R ) ); cleanup: From 13b68fa836e90e953ac11ec8422f7d2b606e61da Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Wed, 22 Apr 2020 20:09:12 +0200 Subject: [PATCH 2/6] Document that Mbed Crypto has moved into Mbed TLS State this prominently in README.md and provide a little migration guidance. Signed-off-by: Gilles Peskine --- CONTRIBUTING.md | 84 +--------------------------------------- README.md | 100 ++++++++---------------------------------------- 2 files changed, 19 insertions(+), 165 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c1ae452e2..899f3bbf9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,82 +1,2 @@ -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: - - - 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. - -Coding Standards ----------------- -- We would ask that contributions conform to [our coding standards](https://tls.mbed.org/kb/development/mbedtls-coding-standards), and that contributions are fully tested before submission, as mentioned in the [Tests](#tests) and [Continuous Integration](#continuous-integration-tests) sections. -- The code should be written in a clean and readable style. -- The code should be written in a portable generic way, that will benefit the whole community, and not only your own needs. -- The code should be secure, and will be reviewed from a security point of view as well. - -Making a Contribution ---------------------- -1. [Check for open issues](https://github.com/ARMmbed/mbedtls/issues) or [start a discussion](https://tls.mbed.org/discussions) around a feature idea or a bug. -1. Fork the [Mbed TLS repository on GitHub](https://github.com/ARMmbed/mbedtls) to start making your changes. As a general rule, you should use the ["development" branch](https://github.com/ARMmbed/mbedtls/tree/development) as a basis. -1. Write a test which shows that the bug was fixed or that the feature works as expected. -1. Send a pull request (PR) and work with us until it gets merged and published. Contributions may need some modifications, so a few rounds of review and fixing may be necessary. We will include your name in the ChangeLog :) -1. For quick merging, the contribution should be short, and concentrated on a single feature or topic. The larger the contribution is, the longer it would take to review it and merge it. -1. All new files should include the [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) standard license header where possible. -1. Ensure that each commit has at least one `Signed-off-by:` line from the committer. If anyone else contributes to the commit, they should also add their own `Signed-off-by:` line. By adding this line, contributor(s) certify that the contribution is made under the terms of the [Developer Certificate of Origin](dco.txt). The contribution licensing is described in the [License section of the README](README.md#License). - -API/ABI Compatibility ---------------------- -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. - -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. - -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. - -When a build is made with the deprecation preprocessor symbols defined, a compiler warning will be generated to warn a user that the function will be removed at some point in the future, notifying users that they should change from the older deprecated function to the newer function at their own convenience. - -Therefore, no changes are permitted to the definition of functions in the public interface which will change the API. Instead the interface can only be changed by its extension. As described above, if a function needs to be changed, a new function needs to be created alongside it, with a new name, and whatever change is necessary, such as a new parameter or the addition of a return value. - -Periodically, the library will remove deprecated functions from the library which will be a breaking change in the API, but such changes will be made only in a planned, structured way that gives sufficient notice to users of the library. - -Long Term Support Branches --------------------------- -Mbed TLS maintains several LTS (Long Term Support) branches, which are maintained continuously for a given period. The LTS branches are provided to allow users of the library to have a maintained, stable version of the library which contains only security fixes and fixes for other defects, without encountering additional features or API extensions which may introduce issues or change the code size or RAM usage, which can be significant considerations on some platforms. To allow users to take advantage of the LTS branches, these branches maintain backwards compatibility for both the public API and ABI. - -When backporting to these branches please observe the following rules: - -1. Any change to the library which changes the API or ABI cannot be backported. -1. All bug fixes that correct a defect that is also present in an LTS branch must be backported to that LTS branch. If a bug fix introduces a change to the API such as a new function, the fix should be reworked to avoid the API change. API changes without very strong justification are unlikely to be accepted. -1. If a contribution is a new feature or enhancement, no backporting is required. Exceptions to this may be additional test cases or quality improvements such as changes to build or test scripts. - -It would be highly appreciated if contributions are backported to LTS branches in addition to the [development branch](https://github.com/ARMmbed/mbedtls/tree/development) by contributors. - -Currently maintained LTS branches are: -1. [mbedtls-2.7](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.7) -1. [mbedtls-2.16](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.16) - - -Tests ------ -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. - -[A Knowledge Base article describing how to add additional tests is available on the Mbed TLS website](https://tls.mbed.org/kb/development/test_suites). - -A test script `tests/scripts/basic-build-test.sh` is available to show test coverage of the library. New code contributions should provide a similar level of code coverage to that which already exists for the library. - -Sample applications, if needed, should be modified as well. - -Continuous Integration Tests ----------------------------- -Once a PR has been made, the Continuous Integration (CI) tests are triggered and run. You should follow the result of the CI tests, and fix failures. - -It is advised to enable the [githooks scripts](https://github.com/ARMmbed/mbedtls/tree/development/tests/git-scripts) prior to pushing your changes, for catching some of the issues as early as possible. - -Documentation -------------- -Mbed TLS is well documented, but if you think documentation is needed, speak out! - -1. All interfaces should be documented through Doxygen. New APIs should introduce Doxygen documentation. -1. Complex parts in the code should include comments. -1. If needed, a Readme file is advised. -1. If a [Knowledge Base (KB)](https://tls.mbed.org/kb) article should be added, write this as a comment in the PR description. -1. A [ChangeLog](https://github.com/ARMmbed/mbedtls/blob/development/ChangeLog) entry should be added for this contribution. +The development of Mbed Crypto has moved to [Mbed TLS](https://github.com/ARMmbed/mbedtls). +Please see the [Mbed TLS contributing guidelines](https://github.com/ARMmbed/mbedtls/blob/development/CONTRIBUTING.md). diff --git a/README.md b/README.md index b716f0881..07e671439 100644 --- a/README.md +++ b/README.md @@ -1,9 +1,24 @@ -# Mbed Crypto library +**The development of Mbed Crypto has moved to [Mbed TLS](https://github.com/ARMmbed/mbedtls).** +No updates will be made to the mbed-crypto repository anymore. -The Mbed cryptography library is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This is a preview release of Mbed Crypto, provided for evaluation purposes only. +Mbed TLS and Mbed Crypto have the same APIs, and the same build system, so most users only need to change the URL to clone or download the library from. + +To save build time and possibly avoid system dependencies, you may want to exclude the X.509 and TLS parts of the library by running + + scripts/config.py crypto + +or + + scripts/config.py crypto_full + +before building Mbed TLS. + +See https://github.com/ARMmbed/mbed-crypto/issues/374 for more details on this migration. ## PSA cryptography API +The cryptography library in Mbed TLS is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This is a preview release of Mbed Crypto, provided for evaluation purposes only. + 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. @@ -16,85 +31,4 @@ The design goals of the PSA cryptography API include: * The interface to algorithms is generic, favoring algorithm agility. * The interface is designed to be easy to use and hard to accidentally misuse. -## Mbed Crypto implementation - -Mbed Crypto is a reference implementation of the PSA cryptography API. It is written in portable C. - -## Documentation - -The Mbed Crypto library implements both the legacy Mbed TLS interfaces to cryptographic primitives (`mbedtls_xxx`) and the new PSA Cryptography interfaces (`psa_xxx`). - -Documentation for the Mbed TLS interfaces in the default library configuration is available as part of the [Mbed TLS documentation](https://tls.mbed.org/api/). - -For the PSA interfaces, please refer to the PSA Cryptography API documents linked from the [PSA cryptography interfaces documentation portal](https://armmbed.github.io/mbed-crypto/psa/#application-programming-interface) for an overview of the library's interfaces and a detailed description of the types, macros and functions that it provides. The API reference is available 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. - -There are currently a few deviations where the library does not yet implement the latest version of the specification. Please refer to the [compliance issues on Github](https://github.com/ARMmbed/mbed-crypto/labels/compliance) for an up-to-date list. - -### Browsable library documentation - -To generate a local copy of the library documentation in HTML format, tailored to your compile-time configuration: - -1. Make sure that [Doxygen](http://www.doxygen.nl/) is installed. We use version 1.8.11 but slightly older or more recent versions should work. -1. Run `make apidoc`. -1. Browse `apidoc/index.html` or `apidoc/modules.html`. - -## Compiling - -You need the following tools to build the library with the provided makefiles: - -* GNU Make or a build tool that CMake supports. -* A C99 toolchain (compiler, linker, archiver). -* Python 2 or Python 3 (either will work) to generate the test code. -* Perl to run the tests. - -If you have a C compiler, such as GCC or Clang, just run `make` in the top-level directory to build the library, a set of unit tests and some sample programs. - -To select a different compiler, set the `CC` variable to the name or path of the compiler and linker (default: `cc`), and set `AR` to a compatible archiver (default: `ar`). For example: -``` -make CC=arm-linux-gnueabi-gcc AR=arm-linux-gnueabi-ar -``` -The provided makefiles pass options to the compiler that assume a GCC-like command-line syntax. To use a different compiler, you may need to pass different values for `CFLAGS`, `WARNINGS_CFLAGS` and `LDFLAGS`. - -To run the unit tests on the host machine, run `make test` from the top-level directory. If you are cross-compiling, copy the test executable from the `tests` directory to the target machine. - -### Compiling as a subproject - -Mbed Crypto supports being built as a subproject of Mbed TLS. Mbed TLS can use Mbed Crypto for its cryptography implementation by using Mbed Crypto as a subproject. - -From the Mbed TLS project repository, CMake can be invoked as follows to build Mbed TLS using Mbed Crypto's `libmbedcrypto`. -``` -mkdir cmake -cd cmake -cmake .. -DUSE_CRYPTO_SUBMODULE=1 -make -j -make test -``` - -When building Mbed Crypto as a subproject of Mbed TLS, the Mbed TLS -configuration file (config.h) is used, and not the Mbed Crypto configuration -file. - -## Example programs - -The `programs/` subdirectory contains sample programs that use the library. Please note that the goal of these sample programs is to demonstrate specific features of the library, and the code may need to be adapted to build a real-world application. - -## Upcoming features - -Future releases of this library will include: - -* A driver programming interface, which makes it possible to use hardware accelerators instead of the default software implementation for chosen algorithms. -* Support for external keys to be stored and manipulated exclusively in a separate cryptoprocessor. -* A configuration mechanism to compile only the algorithms you need for your application. -* A wider set of cryptographic algorithms. - -## License - -Unless specifically indicated otherwise in a file, Mbed TLS files are provided under the [Apache-2.0](https://spdx.org/licenses/Apache-2.0.html) license. See the [LICENSE](LICENSE) file for the full text of this license. 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. - -## Contributing - -We gratefully accept bug reports and contributions from the community. Please see the [contributing guidelines](CONTRIBUTING.md) for details on how to do this. - -## Feedback welcome - 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. From 9c1e0091a8d752fb6723f438070bc589c7f8ff3a Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Wed, 22 Apr 2020 20:15:56 +0200 Subject: [PATCH 3/6] Add deprecation warnings At this point in time, Mbed Crypto has no known security issues. But in the future, it will not be updated if security issues are discovered. So add warnings about the migration to Mbed TLS, but don't break the build yet. Signed-off-by: Gilles Peskine --- CMakeLists.txt | 7 +++++++ Makefile | 4 ++++ include/mbedtls/check_config.h | 4 ++++ 3 files changed, 15 insertions(+) diff --git a/CMakeLists.txt b/CMakeLists.txt index 31b4040fd..f9ba53f75 100644 --- a/CMakeLists.txt +++ b/CMakeLists.txt @@ -241,3 +241,10 @@ if(ENABLE_TESTING) ${CMAKE_CURRENT_BINARY_DIR}/DartConfiguration.tcl COPYONLY) endif() endif() + +message(WARNING "\ +\n ****************************************************************\ +\n **** Mbed Crypto is no longer being updated. *******************\ +\n **** Please use Mbed TLS instead. See README.md. ***************\ +\n ****************************************************************\ +") diff --git a/Makefile b/Makefile index 4fd7f8eaa..c5b42a573 100644 --- a/Makefile +++ b/Makefile @@ -77,6 +77,10 @@ ifndef WINDOWS -scripts/config.py get MBEDTLS_TEST_NULL_ENTROPY && ([ $$? -eq 0 ]) && \ echo '$(NULL_ENTROPY_WARNING)' endif + -echo "****************************************************************" + -echo "**** Mbed Crypto is no longer being updated. *******************" + -echo "**** Please use Mbed TLS instead. See README.md. ***************" + -echo "****************************************************************" clean: $(MAKE) -C library clean diff --git a/include/mbedtls/check_config.h b/include/mbedtls/check_config.h index c3a38301c..df35a168d 100644 --- a/include/mbedtls/check_config.h +++ b/include/mbedtls/check_config.h @@ -30,6 +30,10 @@ #ifndef MBEDTLS_CHECK_CONFIG_H #define MBEDTLS_CHECK_CONFIG_H +#if defined(MBEDTLS_DEPRECATED_WARNING) +#warning "Mbed Crypto is no longer being updated. Please use Mbed TLS instead. See README.md." +#endif + /* * We assume CHAR_BIT is 8 in many places. In practice, this is true on our * target platforms, so not an issue, but let's just be extra sure. From 4099df6fb2ffd0390003857a1f0c5746da41505c Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Wed, 22 Apr 2020 20:18:00 +0200 Subject: [PATCH 4/6] Refuse to build the library if deprecated features are excluded Mbed Crypto is no longer being updated, so using it is deprecated. Don't test with MBEDTLS_DEPRECATED_REMOVED anymore since the library deliberately no longer builds when it's enabled. Signed-off-by: Gilles Peskine --- include/mbedtls/check_config.h | 3 +++ tests/scripts/all.sh | 9 --------- 2 files changed, 3 insertions(+), 9 deletions(-) diff --git a/include/mbedtls/check_config.h b/include/mbedtls/check_config.h index df35a168d..ae7469ec6 100644 --- a/include/mbedtls/check_config.h +++ b/include/mbedtls/check_config.h @@ -30,6 +30,9 @@ #ifndef MBEDTLS_CHECK_CONFIG_H #define MBEDTLS_CHECK_CONFIG_H +#if defined(MBEDTLS_DEPRECATED_REMOVED) +#error "Mbed Crypto is no longer being updated. Please use Mbed TLS instead. See README.md." +#endif #if defined(MBEDTLS_DEPRECATED_WARNING) #warning "Mbed Crypto is no longer being updated. Please use Mbed TLS instead. See README.md." #endif diff --git a/tests/scripts/all.sh b/tests/scripts/all.sh index 17ca34641..fd3177332 100755 --- a/tests/scripts/all.sh +++ b/tests/scripts/all.sh @@ -712,15 +712,6 @@ component_build_deprecated () { msg "test: make, full config + DEPRECATED_WARNING, expect warnings" # ~ 30s make -C tests clean make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-error=deprecated-declarations -DMBEDTLS_TEST_DEPRECATED' tests - - msg "build: make, full config + DEPRECATED_REMOVED, clang -O" # ~ 30s - # No cleanup, just tweak the configuration and rebuild - make clean - scripts/config.py unset MBEDTLS_DEPRECATED_WARNING - scripts/config.py set MBEDTLS_DEPRECATED_REMOVED - # Build with -O -Wextra to catch a maximum of issues. - make CC=clang CFLAGS='-O -Werror -Wall -Wextra' lib programs - make CC=clang CFLAGS='-O -Werror -Wall -Wextra -Wno-unused-function' tests } component_test_depends_curves () { From 93b15619f4c3752cf7cff2ac667f41ef320582a4 Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 23 Apr 2020 18:02:00 +0200 Subject: [PATCH 5/6] MBEDTLS_DEPRECATED_WARNING now always emits a #warning MBEDTLS_DEPRECATED_WARNING now always emits a #warning since this branch as a whole is deprecated. So disable it from most builds. Signed-off-by: Gilles Peskine --- scripts/config.py | 1 + tests/scripts/all.sh | 9 +++++---- 2 files changed, 6 insertions(+), 4 deletions(-) diff --git a/scripts/config.py b/scripts/config.py index 6d4828a95..d6d6c8bca 100755 --- a/scripts/config.py +++ b/scripts/config.py @@ -166,6 +166,7 @@ def include_in_full(name): if name in [ 'MBEDTLS_CTR_DRBG_USE_128_BIT_KEY', 'MBEDTLS_DEPRECATED_REMOVED', + 'MBEDTLS_DEPRECATED_WARNING', 'MBEDTLS_ECDH_VARIANT_EVEREST_ENABLED', 'MBEDTLS_ECP_RESTARTABLE', 'MBEDTLS_ENTROPY_FORCE_SHA256', # Variant toggle, tested separately diff --git a/tests/scripts/all.sh b/tests/scripts/all.sh index fd3177332..603845b98 100755 --- a/tests/scripts/all.sh +++ b/tests/scripts/all.sh @@ -702,16 +702,17 @@ component_test_full_make_gcc_o0 () { } component_build_deprecated () { - msg "build: make, full config + DEPRECATED_WARNING, gcc -O" # ~ 30s + msg "build: make, full config + DEPRECATED_WARNING, gcc -O, expect warnings" # ~ 30s scripts/config.py full scripts/config.py set MBEDTLS_DEPRECATED_WARNING # Build with -O -Wextra to catch a maximum of issues. - make CC=gcc CFLAGS='-O -Werror -Wall -Wextra' lib programs - make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-unused-function' tests + # Expect #warning stating that Mbed Crypto is no longer updated. + make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-error=cpp' lib programs + make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-error=cpp -Wno-unused-function' tests msg "test: make, full config + DEPRECATED_WARNING, expect warnings" # ~ 30s make -C tests clean - make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-error=deprecated-declarations -DMBEDTLS_TEST_DEPRECATED' tests + make CC=gcc CFLAGS='-O -Werror -Wall -Wextra -Wno-error=cpp -Wno-error=deprecated-declarations -DMBEDTLS_TEST_DEPRECATED' tests } component_test_depends_curves () { From cd2efd60b3a7f5ac6baec49eeb2ba474e3c3f18b Mon Sep 17 00:00:00 2001 From: Gilles Peskine Date: Thu, 23 Apr 2020 18:05:34 +0200 Subject: [PATCH 6/6] Update public feedback channel Signed-off-by: Gilles Peskine --- README.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 07e671439..f305553f7 100644 --- a/README.md +++ b/README.md @@ -31,4 +31,5 @@ The design goals of the PSA cryptography API include: * The interface to algorithms is generic, favoring algorithm agility. * The interface is designed to be easy to use and hard to accidentally misuse. -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. +Arm welcomes feedback on the design of the API. If you think something could be improved, please discuss it on the [`psa-crypto` mailing list](https://lists.trustedfirmware.org/mailman/listinfo/psa-crypto). +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 through this email is treated confidentially.