Version 1 vs 2
Version 1 vs 2
Edits
Edits
- Edit by janos.follath, Version 2
- Apr 30 2020 11:59 AM
- Edit by janos.follath, Version 1
- Apr 30 2020 11:57 AM
Original Change | Most Recent Change |
Edit Older Version 1... | Edit Current Version 2... |
Content Changes
Content Changes
The cryptography library in Mbed TLS is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This cryptography library is called Mbed Crypto and used to be developed in its own github repository.
The development of Mbed Crypto has moved to Mbed TLS. No updates will be made to the mbed-crypto repository anymore.
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.
The rest of this document gives more details on this migration.
## Building Mbed/PSA Crypto from the mbedtls repo
This document explains how to build the Mbed Crypto library (the current incarnation of the PSA Crypto library) from the mbedtls repository.
The intended audience is users of Mbed Crypto or PSA Crypto who used to get it from the mbed-crypto repository, and will now need to get it from the mbedtls repository. Users who have always been getting Mbed Crypto from the mbedtls repository and building it as part of Mbed TLS are unaffected.
### Summary
- Run` scripts/config.py crypto` before you build;
- build as usual;
- keep `libmbedcrypto.a` or `libmbedcrypto.so`;
- discard the other library files if you don't need them.
### When using the default config.h
You can just build as usual (using `make` or `cmake`+`make`) and only keep `libmbedcrypto.a` from the build results, discarding the other libraries.
Alternatively, if you want to avoid building the X.509 and TLS libraries before discarding them, you can run `scripts/config.py crypto` before running `make` (possibly after `cmake`). This will still create empty files for the
X.509 and TLS libraries, but not waste resources building them.
### When starting from the default config.h and adapting it with config.py
If you're using a custom `config.h` derived from the default one by running a number of `scripts/config.py set/unset XXX` commands, then you can just append `scripts/config.py crypto` to your list of existing calls to `config.py` and
build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a user config file
If you're starting from the default `config.h` but customizing it using a user config file, by setting the `MBEDTLS_USER_CONFIG_FILE`, then you can just run `cripts/config.py crypto` before your build as usual. This will modify the default `config.h` but will keep your user config file unchanged.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a standalone config.h
If you're using a custom `stand-alone config.h`, that is one that's maintained independently and replaces the default one (either by overwriting it with your file, or setting `MBEDTLS_CONFIG_FILE` in your build environment), then you
can just keep your file as is (assuming you're only setting crypto options in it) and build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
If your custom standalone `config.h` was not clean and included X.509 or TLS settings despite targeting Mbed Crypto, you might get errors from `check_config.h`. These would be resolved by running `scripts/config.py -f <path_to/your_config.h> crypto` just one time. After that you can keep using and maintaining your standalone config.h as usual.
The cryptography library in Mbed TLS is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This cryptography library is called Mbed Crypto and used to be developed in its own github repository.
The development of Mbed Crypto has moved to Mbed TLS. No updates will be made to the mbed-crypto repository anymore.
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.
The rest of this document gives more details on this migration.
## Building Mbed/PSA Crypto from the mbedtls repo
This document explains how to build the Mbed Crypto library (the current incarnation of the PSA Crypto library) from the mbedtls repository.
The intended audience is users of Mbed Crypto or PSA Crypto who used to get it from the mbed-crypto repository, and will now need to get it from the mbedtls repository. Users who have always been getting Mbed Crypto from the mbedtls repository and building it as part of Mbed TLS are unaffected.
### Summary
- Run` scripts/config.py crypto` before you build;
- build as usual;
- keep `libmbedcrypto.a` or `libmbedcrypto.so`;
- discard the other library files if you don't need them.
### When using the default config.h
You can just build as usual (using `make` or `cmake`+`make`) and only keep `libmbedcrypto.a` from the build results, discarding the other libraries.
Alternatively, if you want to avoid building the X.509 and TLS libraries before discarding them, you can run `scripts/config.py crypto` before running `make` (possibly after `cmake`). This will still create empty files for the
X.509 and TLS libraries, but not waste resources building them.
### When starting from the default config.h and adapting it with config.py
If you're using a custom `config.h` derived from the default one by running a number of `scripts/config.py set/unset XXX` commands, then you can just append `scripts/config.py crypto` to your list of existing calls to `config.py` and
build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a user config file
If you're starting from the default `config.h` but customizing it using a user config file, by setting the `MBEDTLS_USER_CONFIG_FILE`, then you can just run `cripts/config.py crypto` before your build as usual. This will modify the default `config.h` but will keep your user config file unchanged.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a standalone config.h
If you're using a custom `stand-alone config.h`, that is one that's maintained independently and replaces the default one (either by overwriting it with your file, or setting `MBEDTLS_CONFIG_FILE` in your build environment), then you
can just keep your file as is (assuming you're only setting crypto options in it) and build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
If your custom standalone `config.h` was not clean and included X.509 or TLS settings despite targeting Mbed Crypto, you might get errors from `check_config.h`. These would be resolved by running `scripts/config.py -f <path_to/your_config.h> crypto` just one time. After that you can keep using and maintaining your standalone config.h as usual.
The cryptography library in Mbed TLS is a reference implementation of the cryptography interface of the Arm Platform Security Architecture (PSA). This cryptography library is called Mbed Crypto and used to be developed in its own github repository.
The development of Mbed Crypto has moved to Mbed TLS. No updates will be made to the mbed-crypto repository anymore.
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.
The rest of this document gives more details on this migration.
## Building Mbed/PSA Crypto from the mbedtls repo
This document explains how to build the Mbed Crypto library (the current incarnation of the PSA Crypto library) from the mbedtls repository.
The intended audience is users of Mbed Crypto or PSA Crypto who used to get it from the mbed-crypto repository, and will now need to get it from the mbedtls repository. Users who have always been getting Mbed Crypto from the mbedtls repository and building it as part of Mbed TLS are unaffected.
### Summary
- Run` scripts/config.py crypto` before you build;
- build as usual;
- keep `libmbedcrypto.a` or `libmbedcrypto.so`;
- discard the other library files if you don't need them.
### When using the default config.h
You can just build as usual (using `make` or `cmake`+`make`) and only keep `libmbedcrypto.a` from the build results, discarding the other libraries.
Alternatively, if you want to avoid building the X.509 and TLS libraries before discarding them, you can run `scripts/config.py crypto` before running `make` (possibly after `cmake`). This will still create empty files for the
X.509 and TLS libraries, but not waste resources building them.
### When starting from the default config.h and adapting it with config.py
If you're using a custom `config.h` derived from the default one by running a number of `scripts/config.py set/unset XXX` commands, then you can just append `scripts/config.py crypto` to your list of existing calls to `config.py` and
build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a user config file
If you're starting from the default `config.h` but customizing it using a user config file, by setting the `MBEDTLS_USER_CONFIG_FILE`, then you can just run `cripts/config.py crypto` before your build as usual. This will modify the default `config.h` but will keep your user config file unchanged.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
Unlike the case of using the default config, running `scripts/config.py crypto` is required here, to avoid `check_config.h` complaining if your custom crypto build is not compatible with the default TLS options.
### When using a standalone config.h
If you're using a custom `stand-alone config.h`, that is one that's maintained independently and replaces the default one (either by overwriting it with your file, or setting `MBEDTLS_CONFIG_FILE` in your build environment), then you
can just keep your file as is (assuming you're only setting crypto options in it) and build as usual.
Again, this will create empty files for the X.509 and TLS libraries, but not waste resources building them. Just discard those files and use `libmbedcrypto.a` as usual.
If your custom standalone `config.h` was not clean and included X.509 or TLS settings despite targeting Mbed Crypto, you might get errors from `check_config.h`. These would be resolved by running `scripts/config.py -f <path_to/your_config.h> crypto` just one time. After that you can keep using and maintaining your standalone config.h as usual.