lib/mbedtls
1
0
Fork 0
mirror of https://github.com/Mbed-TLS/mbedtls.git synced 2025-07-29 11:41:15 +03:00
Code Activity

Update references to old Github organisation

Browse Source 
Replace references to ARMmbed organisation with the new
org, Mbed-TLS, following project migration.

Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
This commit is contained in:
Dave Rodgman
2022-03-31 14:07:01 +01:00
parent a980adf4ce
commit 017a19997a
20 changed files with 53 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
docs/architecture/psa-migration/psa-limitations.md
View File

@ -27,12 +27,12 @@ PSA Crypto has an API for FFDH, but it's not implemented in Mbed TLS yet.
(Regarding FFDH, see the next section as well.) See issue [3261][ffdh] on
github.
[ffdh]: https://github.com/ARMmbed/mbedtls/issues/3261
[ffdh]: https://github.com/Mbed-TLS/mbedtls/issues/3261
PSA Crypto has an experimental API for EC J-PAKE, but it's not implemented in
Mbed TLS yet. See the [EC J-PAKE follow-up EPIC][ecjp] on github.
[ecjp]: https://github.com/orgs/ARMmbed/projects/18#column-15836385
[ecjp]: https://github.com/orgs/Mbed-TLS/projects/1#column-17950140
Arbitrary parameters for FFDH
-----------------------------

8
docs/architecture/psa-migration/strategy.md
View File

@ -42,7 +42,7 @@ are:
- it's incompatible with `MBEDTLS_ECP_RESTARTABLE`;
- historical: used to be incompatible
`MBEDTLS_PSA_CRYPTO_KEY_ID_ENCODES_OWNER` (fixed early 2022, see
<https://github.com/ARMmbed/mbedtls/issues/5259>);
<https://github.com/Mbed-TLS/mbedtls/issues/5259>);
- it does not work well with `MBEDTLS_PSA_CRYPTO_CONFIG` (could compile with
both of them, but then `MBEDTLS_PSA_CRYPTO_CONFIG` won't have the desired
effect)
@ -99,8 +99,8 @@ an algorithm through a PSA driver only, without building the software
implementation of that algorithm. But then the TLS code would consider the
algorithm unavailable.
This is tracked in https://github.com/ARMmbed/mbedtls/issues/3674 and
https://github.com/ARMmbed/mbedtls/issues/3677. But now that I look at it with
This is tracked in https://github.com/Mbed-TLS/mbedtls/issues/3674 and
https://github.com/Mbed-TLS/mbedtls/issues/3677. But now that I look at it with
fresh eyes, I don't think the approach we were planning to use would actually
works. This needs more design effort.
@ -138,7 +138,7 @@ available in entropy-less builds. (Then code using those functions still needs
to have one version using it, for entropy-less builds, and one version using
the standard function, for driver support in build with entropy.)
See https://github.com/ARMmbed/mbedtls/issues/5156
See https://github.com/Mbed-TLS/mbedtls/issues/5156
Taking advantage of the existing abstractions layers - or not
=============================================================

2
docs/architecture/tls13-support.md
View File

@ -324,7 +324,7 @@ TLS 1.3 specific coding rules:
```
- To mitigate what happened here
(https://github.com/ARMmbed/mbedtls/pull/4882#discussion_r701704527) from
(https://github.com/Mbed-TLS/mbedtls/pull/4882#discussion_r701704527) from
happening again, use always a local variable named `p` for the reading
pointer in functions parsing TLS 1.3 data, and for the writing pointer in
functions writing data into an output buffer and only that variable. The