Merge branch 'development' into convert_NO_SHA384_to_positive

Conflicts:
	library/version_features.c
	programs/test/query_config.c

Files were removed in development branch and modified by current branch.
Conflicts fixes by removing them.

docs/3.0-migration-guide.d/remove-max-content-len.md

@@ -0,0 +1,10 @@
+Remove the `MBEDTLS_SSL_MAX_CONTENT_LEN` configuration option
+-------------------------------------------------------------
+
+This affects users who use the `MBEDTLS_SSL_MAX_CONTENT_LEN` option to
+set the maximum length of incoming and outgoing plaintext fragments,
+which can save memory by reducing the size of the TLS I/O buffers.
+
+This option is replaced by the more fine-grained options
+`MBEDTLS_SSL_IN_CONTENT_LEN` and `MBEDTLS_SSL_OUT_CONTENT_LEN` that set
+the maximum incoming and outgoing plaintext fragment lengths, respectively.

docs/3.0-migration-guide.d/remove-null-entropy.md

@@ -0,0 +1,11 @@
+Remove the option to build the library without any entropy sources
+------------------------------------------------------------------
+
+This does not affect users who use the default `config.h`, as this option was
+already off by default.
+
+If you were using the `MBEDTLS_TEST_NULL_ENTROPY` option and your platform
+doesn't have any entropy source, you should use `MBEDTLS_ENTROPY_NV_SEED`
+and make sure your device is provisioned with a strong random seed.
+Alternatively, for testing purposes only, you can create and register a fake
+entropy function.

docs/3.0-migration-guide.d/remove_ssl_record_checking.md

@@ -0,0 +1,13 @@
+Remove MBEDTLS_SSL_RECORD_CHECKING option and enable its action by default
+--------------------------------------------------------------------------
+
+This change does not affect users who use the default config.h, as the
+option MBEDTLS_SSL_RECORD_CHECKING was already on by default.
+
+This option was added only to control compilation of one function,
+mbedtls_ssl_check_record(), which is only useful in some specific cases, so it
+was made optional to allow users who don't need it to save some code space.
+However, the same effect can be achieve by using link-time garbage collection.
+
+Users who changed the default setting of the option need to change the config/
+build system to remove that change.

docs/3.0-migration-guide.d/sha512-output-type.md

@@ -0,0 +1,8 @@
+SHA-512 and SHA-256 output type change
+--------------------------
+
+The output parameter of `mbedtls_sha256_finish_ret()`, `mbedtls_sha256_ret()`, `mbedtls_sha512_finish_ret()`, `mbedtls_sha512_ret()` now has a pointer type rather than array type. This makes no difference in terms of C semantics, but removes spurious warnings in some compilers when outputting a SHA-384 hash into a 48-byte buffer or a SHA-224 hash into a 28-byte buffer.
+
+This makes no difference to a vast majority of applications. If your code takes a pointer to one of these functions, you may need to change the type of the pointer.
+
+Alternative implementations of the SHA256 and SHA512 modules must adjust their functions' prototype accordingly.

docs/3.0-migration-guide.d/ssl-error-code-cleanup.md

@@ -0,0 +1,20 @@
+Removal of some SSL error codes
+-----------------------------------------------------------------
+
+This affects users manually checking for the following error codes:
+- `MBEDTLS_ERR_SSL_CERTIFICATE_REQUIRED`
+- `MBEDTLS_ERR_SSL_INVALID_VERIFY_HASH`
+- `MBEDTLS_ERR_SSL_CERTIFICATE_TOO_LARGE`
+
+Migration paths:
+- `MBEDTLS_ERR_SSL_CERTIFICATE_REQUIRED` and `MBEDTLS_ERR_SSL_INVALID_VERIFY_HASH`
+  should never be returned from Mbed TLS, and there is no need to check for it.
+  Users should simply remove manual checks for those codes, and let the Mbed TLS
+  team know if -- contrary to the team's understanding -- there is in fact a situation
+  where one of them was ever returned.
+- `MBEDTLS_ERR_SSL_CERTIFICATE_TOO_LARGE` has been removed, and
+  `MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL` is returned instead if the user's own certificate
+  is too large to fit into the output buffers. Users should check for
+  `MBEDTLS_ERR_SSL_BUFFER_TOO_SMALL` instead, and potentially compare the size of their
+  own certificate against the configured size of the output buffer to understand if
+  the error is due to an overly large certificate.

docs/proposed/psa-driver-interface.md

@@ -305,9 +305,12 @@ This family requires the following type and entry points:
 * `"key_derivation_setup"`: called by `psa_key_derivation_setup()`.
 * `"key_derivation_set_capacity"`: called by `psa_key_derivation_set_capacity()`. The core will always enforce the capacity, therefore this function does not need to do anything for algorithms where the output stream only depends on the effective generated length and not on the capacity.
 * `"key_derivation_input_bytes"`: called by `psa_key_derivation_input_bytes()` and `psa_key_derivation_input_key()`. For transparent drivers, when processing a call to `psa_key_derivation_input_key()`, the core always calls the applicable driver's `"key_derivation_input_bytes"` entry point.
+* `"key_derivation_input_integer"`: called by `psa_key_derivation_input_integer()`.
 * `"key_derivation_input_key"` (opaque drivers only)
 * `"key_derivation_output_bytes"`: called by `psa_key_derivation_output_bytes()`; also by `psa_key_derivation_output_key()` for transparent drivers.
 * `"key_derivation_output_key"`: called by `psa_key_derivation_output_key()` for transparent drivers when deriving an asymmetric key pair, and also for opaque drivers.
+* `"key_derivation_verify_bytes"` (opaque drivers only).
+* `"key_derivation_verify_key"` (opaque drivers only).
 * `"key_derivation_abort"`: called by all key derivation functions of the PSA Cryptography API.
 
 TODO: key input and output for opaque drivers; deterministic key generation for transparent drivers