Don't link to the proposed specifications: they aren't good entry points
because they describe what we want to achieve, not what exists today. The
guide links to them, that's enough.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Our code is still compatible with Python 3.5 at the time of writing, but we
don't want to commit to that.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The wording wasn't quite right for 3.0.0 and up: there's nothing special
about Python and sample programs (that was true in the end times of 2.x, but
not since 3.0). Python is not needed in a release unless you want to build
the tests or you want to integrate PSA drivers without writing your own C
wrappers.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Everything discussed in "Upcoming features" section is now available as a
usable, but incomplete feature (except "wider set of cryptographic
algorithms", but that doesn't need to be said). So replace it by a section
that briefly presents these features: drivers, and MBEDTLS_PSA_CRYPTO_CONFIG
which is primarily useful with drivers and thus doesn't get its own section.
Include an explicit note that the driver interface can still change. At this
time, it's the only place where we say that the driver interface is not
covered by the (application) interface stability promise.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
Our build scripts invoke `python3` in preference to `python`, so make the
default instruction use `python3`. On many systems (macOS, some Linux),
`python` invokes Python 2 which our scripts do not support.
Suggest --user by default. It's usually the right thing outside of venvs.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
curves.pl, depends-hashes.pl, key-exchanges.pl and depends-pkalgs.pl are now superseded by depends.py.
Update all references to them accordingly.
Signed-off-by: Andrzej Kurek <andrzej.kurek@arm.com>
Driver implementers need to regenerate wrappers. This will use Jinja2 as
discussed in
https://github.com/ARMmbed/mbedtls/pull/5067#discussion_r738794607
On the development branch, driver integration is always needed to generate
the driver wrapper and thus to build the library, so this requirement
applies to everyone, not just driver implementers. In releases, we plan to
include a default driver wrapper with support for basic use cases only,
meaning that the line `-r driver.requirements.txt` should be removed from
`basic.requirements.txt` in releases.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
The makefile build specifies -L. -lmbedx509 -lmbedcrypto flags first,
and only then object files referencing symbols from those libraries.
In this order the linker will not add the linked libraries to the
DT_NEEDED section because they are not referenced yet (at least that
happens for me on ubuntu 20.04 with the default gnu compiler tools).
By first specifying the object files and then the linked libraries, we
do end up with libmbedx509 and libmbedcrypto in the DT_NEEDED sections.
This way running dlopen(...) on libmedtls.so just works.
Note that the CMake build does this by default.
Signed-off-by: Harmen Stoppels <harmenstoppels@gmail.com>
Add a line in the README explaining that CMake will generate
the files it needs automatically on non-Windows systems
when not cross-compiling.
Signed-off-by: David Horstmann <david.horstmann@arm.com>
This information was already present in SECURITY.md and SUPPORT.md, but that
wasn't very apparent.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
This change enables automatic detection and consumption of Mbed TLS
library targets from within other CMake projects. By generating an
`MbedTLSConfig.cmake` file, consuming projects receive a more complete
view of these targets, allowing them to be used as dependencies which
properly inherit the transitive dependencies of the libraries.
This is fairly fragile, as it seems Mbed TLS's libraries do not appear
to properly model their dependencies on other targets, including
third-party dependencies. It is, however, sufficient for building and
linking the compiled Mbed TLS libraries when there are no third-party
dependencies involved. Further work is needed for more complex
use-cases, but this will likely meet the needs of most projects.
Resolves#298. Probably useful for #2857.
Signed-off-by: Chris Kay <chris.kay@arm.com>
Move all the PSA crypto APIs using key handles
to use key identifiers but psa_key_open() and
psa_key_close(). This is done without modifying
any test as key handles and key identifiers are
now the same.
Update the library modules using PSA crypto APIs
to get rid of key handles.
Programs and unit tests are updated to not use
key handles in subsequent commits, not in this
one.
Signed-off-by: Ronald Cron <ronald.cron@arm.com>
The Doxygen-generated manual includes PSA interfaces, so we don't need
to tell people to read the specification instead. Do link to the
specification portal, but from the PSA API section, not from the Mbed
TLS documentation section.
Adapted from the section in Mbed Crypto, with the addition of specific
compiler versions. Only mention Python 3; Python 2 may still work but
it is no longer supported upstream so we will not maintain
compatibility anymore.
The Mbed TLS project no longer requires a CLA. Contributions from now on
must be made under both Apache-2.0 AND GPL-2.0-or-later licenses, to enable
LTS (Long Term Support) branches of the software to continue to be provided
under either Apache-2.0 OR GPL-2.0-or-later. Contributors must accept the
terms of the Developer Certificate of Origin (DCO) by adding a Signed-off-by:
line to each commit message.
The software on the development branch continues to be provided under
Apache-2.0.
Update README.md, CONTRIBUTING.md and pull_request_template.md to explain
the new licensing model. Add a copy of the DCO to the project.
Expand the full Apache-2.0 license text in the LICENSE file and remove the
redundant apache-2.0.txt.
Signed-off-by: Dan Handley <dan.handley@arm.com>
