yuzu-emu/mbedtls
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

Minor presentation improvements

Browse source 
Minor wording improvement and cosmetic formatting improvements.

Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This commit is contained in:
Gilles Peskine 2021-03-16 12:04:44 +01:00
parent 80c02af03c
commit a23df13e52
2 changed files with 22 additions and 14 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
BRANCHES.md
View file

@ -2,9 +2,11 @@
At any point in time, we have a number of maintained branches consisting of:
- the development branch: this is where new features lands, as well as bug
fixes and security fixes
- one or more LTS branches: these only get bug fixes and security fixes.
- The [`development`](https://github.com/ARMmbed/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.
We use [Semantic Versioning](https://semver.org/). In particular, we maintain
API compatibility in the development branch between major version changes. We
@ -13,13 +15,17 @@ details.
## Backwards Compatibility
If you have code that's working and secure with Mbed TLS x.y.z, then you
should be able to re-compile it without modification with any later release
x.y'.z' with the same major version number, and your code will still build, be
secure, and work - unless it was relying on something that became insecure in
the meantime (for example, crypto that was found to be weak). In case security
comes in conflict with backwards compatibility, we will put security first,
but always attempt to provide a compatibility option.
We maintain API compatibility in released versions of Mbed TLS. If you have
code that's working and secure with Mbed TLS x.y.z and does not rely on
undocumented features, then you should be able to re-compile it without
modification with any later release x.y'.z' with the same major version
number, and your code will still build, be secure, and work.
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
@ -37,8 +43,8 @@ CONTRIBUTING](CONTRIBUTING.md#cackwords-compatibility).
The following branches are currently maintained:
- [development](https://github.com/ARMmbed/mbedtls/)
- [mbedtls-2.16](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.16)
- [`development`](https://github.com/ARMmbed/mbedtls/)
- [`mbedtls-2.16`](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.16)
maintained until at least the end of 2021, see
<https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16>
- [mbedtls-2.7](https://github.com/ARMmbed/mbedtls/tree/mbedtls-2.7) - end of life in March 2021!

6
SECURITY.md
View file

@ -6,7 +6,8 @@ send an email to the security team at
## Security Incident Handling Process
Our security process is detailled in our [security
Our security process is detailled in our
[security
center](https://developer.trustedfirmware.org/w/mbed-tls/security-center/).
Its primary goal is to ensure fixes are ready to be deployed when the issue
@ -14,5 +15,6 @@ goes public.
## Maintained branches
Only the maintained branches, as listed in BRANCHES.md, get security fixes.
Only the maintained branches, as listed in [`BRANCHES.md`](BRANCHES.md),
get security fixes.
Users are urged to always use the latest version of a maintained branch.