From d50f7865ea3c8424bcdef07112d5fe40c5a45cb7 Mon Sep 17 00:00:00 2001 From: Simon Butcher Date: Tue, 3 Jul 2018 16:11:44 +0100 Subject: [PATCH 1/5] Update the CONTRIBUTING.md file for LTS branches The CONTRIBUTING.md referred to 'legacy' branches instead of LTS branches, and also referenced mbedtls-1.3 which is no longer maintained, and omitted mbedtls-2.7 which is. --- CONTRIBUTING.md | 25 ++++++++++++++----------- 1 file changed, 14 insertions(+), 11 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 3c6dc74c8..2257a615d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -26,19 +26,22 @@ Making a Contribution 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. Mbed TLS is released under the Apache license, and as such, all the added files should include the Apache license header. -Backports ---------- -Mbed TLS maintains some legacy branches, which are released as LTS versions. Mbed TLS should follow backwards compatibility rules, to fit with existing users. As such, backporting to these branches should be handled according to the following rules: - -1. If the contribution is a new feature or enhancement, no backporting is needed. -1. Bug fixes should be backported to the legacy branches containing these bugs. -1. Changes in the API do not require backporting. If a bug fix introduced a new API, such as new error codes, the bug fix should be implemented differently in the legacy branch. +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 version of the library which contains security fixes and fixes for other defects, without encountering any API changes or requiring changes in their own code. 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. Generally, all changes to the library which change the API cannot be backported. + 2. All bug fixes must be backported to the LTS branches if they correct a defect in an 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. + 3. If a contribution is a new feature or enhancement, no backporting is required. Exceptions to this may be addtional test cases or quality improvements such as changes to 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). + +Currently maintained LTS branches are: -It would be highly appreciated if a contribution would be backported to a legacy branch in addition to the [development branch](https://github.com/ARMmbed/mbedtls/tree/development). -At the moment, the legacy branches are: - -1. [mbedtls-1.3](https://github.com/ARMmbed/mbedtls/tree/mbedtls-1.3) 1. [mbedtls-2.1](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.1) +1. [mbedtls-2.7](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.7) Tests ----- From 7870ec12c468ca65511b9865ce85200f6e77063e Mon Sep 17 00:00:00 2001 From: Simon Butcher Date: Fri, 20 Jul 2018 19:39:10 +0100 Subject: [PATCH 2/5] Add API/ABI section to CONTRIBUTING.md Added a section on API/ABI compatibility on the development branch to the CONTRIBUTING.md guidelines. Also added to the testing section, refined the LTS section and changed some formatting for consistency. --- CONTRIBUTING.md | 62 ++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 49 insertions(+), 13 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 2257a615d..e79feaa3c 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,11 +5,13 @@ We gratefully accept bug reports and contributions from the community. There are - 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. + Contributor License Agreement (CLA) ----------------------------------- - All contributions, whether large or small, require a Contributor's License Agreement (CLA) to be accepted. This is because source code can possibly fall under copyright law and we need your consent to share in the ownership of the copyright. - To accept the Contributor’s License Agreement (CLA), individual contributors can do this by creating an Mbed account and [accepting the online agreement here with a click through](https://developer.mbed.org/contributor_agreement/). Alternatively, for contributions from corporations, or those that do not wish to create an Mbed account, a slightly different agreement can be found [here](https://www.mbed.com/en/about-mbed/contributor-license-agreements/). This agreement should be signed and returned to Arm as described in the instructions given. + 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. @@ -17,6 +19,7 @@ Coding Standards - 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. @@ -26,41 +29,74 @@ Making a Contribution 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. Mbed TLS is released under the Apache license, and as such, all the added files should include the Apache license header. + +API/ABI Compatibility +--------------------- + +API compatibility is maintained between versions of Mbed TLS on the main development branch. This is to ensure that when users of the library upgrade to a newer version of the library, there will be no API changes that may cause their code to fail to compile and it will not be necessary for them to make any changes to their own code. + +Where changes to the interface are necessary, functions in the public interface which need to be removed or replaced will be marked as 'deprecated', with the preprocessor symbols `MBEDTLS_DEPRECATED_WARNING` and `MBEDTLS_DEPRECATED_REMOVED`. Therefore when a build is made with those symbols defined, a compiler warning will be generated to warn a user that the function will be removed at some point in the future. + +It is also desirable to preserve ABI compatibility on the main development branch, and generally ABI changes need to be justifiable by enhancement and new features, to extend the interface. This is to again minimise the impact on users upgrading to newer versions of the library. + +As a consequence, this means there can be no change to the definition of functions in the public API, nor removal of elements in structs that make up part of the public interface. Instead 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 wat 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 version of the library which contains security fixes and fixes for other defects, without encountering any API changes or requiring changes in their own code. To allow users to take advantage of the LTS branches, these branches maintain backwards compatibility for both the public API and ABI. +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. Generally, all changes to the library which change the API cannot be backported. - 2. All bug fixes must be backported to the LTS branches if they correct a defect in an 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. - 3. If a contribution is a new feature or enhancement, no backporting is required. Exceptions to this may be addtional test cases or quality improvements such as changes to scripts. + 1. Any change to the library which changes the API or ABI cannot be backported. -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). + 2. 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. + + 3. If a contribution is a new feature or enhancement, no backporting is required. Exceptions to this may be addtional 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.1](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.1) -1. [mbedtls-2.7](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.7) + +2. [mbedtls-2.7](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.7) + 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 an elaborate test suite in `tests/` that initially requires Perl to generate the tests 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. +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 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. +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 should be well documented. If 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. + +2. Complex parts in the code should include comments. + +3. If needed, a Readme file is advised. + +4. If a [Knowledge Base (KB)](https://tls.mbed.org/kb) article should be added, write this as a comment in the PR description. + +5. A [ChangeLog](https://github.com/ARMmbed/mbedtls/blob/development/ChangeLog) entry should be added for this contribution. + From 10f9663fcb933421068efdec0ee24bcbd3e9af09 Mon Sep 17 00:00:00 2001 From: Simon Butcher Date: Mon, 23 Jul 2018 16:10:36 +0100 Subject: [PATCH 3/5] Added clarification to CONTRIBUTING.md Added rationale as to when API changes are permitted, and clarified why we try to preserve the API/ABI. --- CONTRIBUTING.md | 20 +++++++------------- 1 file changed, 7 insertions(+), 13 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e79feaa3c..f55fc288e 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -5,13 +5,11 @@ We gratefully accept bug reports and contributions from the community. There are - 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. - Contributor License Agreement (CLA) ----------------------------------- - All contributions, whether large or small, require a Contributor's License Agreement (CLA) to be accepted. This is because source code can possibly fall under copyright law and we need your consent to share in the ownership of the copyright. - To accept the Contributor’s License Agreement (CLA), individual contributors can do this by creating an Mbed account and [accepting the online agreement here with a click through](https://developer.mbed.org/contributor_agreement/). Alternatively, for contributions from corporations, or those that do not wish to create an Mbed account, a slightly different agreement can be found [here](https://www.mbed.com/en/about-mbed/contributor-license-agreements/). This agreement should be signed and returned to Arm as described in the instructions given. - 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. @@ -19,7 +17,6 @@ Coding Standards - 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. @@ -29,20 +26,19 @@ Making a Contribution 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. Mbed TLS is released under the Apache license, and as such, all the added files should include the Apache license header. - 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. -API compatibility is maintained between versions of Mbed TLS on the main development branch. This is to ensure that when users of the library upgrade to a newer version of the library, there will be no API changes that may cause their code to fail to compile and it will not be necessary for them to make any changes to their own code. +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 the interface are necessary, functions in the public interface which need to be removed or replaced will be marked as 'deprecated', with the preprocessor symbols `MBEDTLS_DEPRECATED_WARNING` and `MBEDTLS_DEPRECATED_REMOVED`. Therefore when a build is made with those symbols defined, a compiler warning will be generated to warn a user that the function will be removed at some point in the future. +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. -It is also desirable to preserve ABI compatibility on the main development branch, and generally ABI changes need to be justifiable by enhancement and new features, to extend the interface. This is to again minimise the impact on users upgrading to newer versions of the library. +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. -As a consequence, this means there can be no change to the definition of functions in the public API, nor removal of elements in structs that make up part of the public interface. Instead 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 wat that gives sufficient notice to users of the library. +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 -------------------------- @@ -78,17 +74,15 @@ 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 should be well documented. If documentation is needed, speak out! +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. From 5a5d03f025dcd170e4580ca5c9c18a6fc85b2f8e Mon Sep 17 00:00:00 2001 From: Simon Butcher Date: Mon, 23 Jul 2018 16:16:04 +0100 Subject: [PATCH 4/5] Add test guidelines to CONTRIBUTING.md --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index f55fc288e..83e04f8ee 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -68,6 +68,8 @@ As mentioned, tests that show the correctness of the feature or bug fix should b 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 knowledgebase 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. From 6965f771de04408d4050d75576c64b7188ecd3f1 Mon Sep 17 00:00:00 2001 From: Simon Butcher Date: Mon, 23 Jul 2018 23:57:07 +0100 Subject: [PATCH 5/5] Fix use of Knowledge Base in documentation Made the use of 'Knowledge Base' consistent in the CONTRIBUTING.md and README.md files. --- CONTRIBUTING.md | 2 +- README.md | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 83e04f8ee..8fb8ab8fa 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -68,7 +68,7 @@ As mentioned, tests that show the correctness of the feature or bug fix should b 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 knowledgebase article describing how to add additional tests is available on the Mbed TLS website](https://tls.mbed.org/kb/development/test_suites). +[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 diff --git a/README.md b/README.md index ced36e192..6345848d2 100644 --- a/README.md +++ b/README.md @@ -82,7 +82,7 @@ Please note that setting `CFLAGS` overrides its default value of `-O2` and setti Depending on your platform, you might run into some issues. Please check the Makefiles in `library/`, `programs/` and `tests/` for options to manually add or remove for specific platforms. You can also check [the Mbed TLS Knowledge Base](https://tls.mbed.org/kb) for articles on your platform or issue. -In case you find that you need to do something else as well, please let us know what, so we can add it to the [Mbed TLS knowledge base](https://tls.mbed.org/kb). +In case you find that you need to do something else as well, please let us know what, so we can add it to the [Mbed TLS Knowledge Base](https://tls.mbed.org/kb). ### CMake @@ -192,7 +192,7 @@ We provide some non-standard configurations focused on specific use cases in the Porting Mbed TLS ---------------- -Mbed TLS can be ported to many different architectures, OS's and platforms. Before starting a port, you may find the following knowledge base articles useful: +Mbed TLS can be ported to many different architectures, OS's and platforms. Before starting a port, you may find the following Knowledge Base articles useful: - [Porting Mbed TLS to a new environment or OS](https://tls.mbed.org/kb/how-to/how-do-i-port-mbed-tls-to-a-new-environment-OS) - [What external dependencies does Mbed TLS rely on?](https://tls.mbed.org/kb/development/what-external-dependencies-does-mbedtls-rely-on)