Update references to old Github organisation
Replace references to ARMmbed organisation with the new
org, Mbed-TLS, following project migration.
Signed-off-by: Dave Rodgman <dave.rodgman@arm.com>
diff --git a/docs/architecture/psa-migration/psa-limitations.md b/docs/architecture/psa-migration/psa-limitations.md
index a7c4afb..31adec3 100644
--- a/docs/architecture/psa-migration/psa-limitations.md
+++ b/docs/architecture/psa-migration/psa-limitations.md
@@ -27,12 +27,12 @@
(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
-----------------------------
diff --git a/docs/architecture/psa-migration/strategy.md b/docs/architecture/psa-migration/strategy.md
index 205c6cd..d63bb8e 100644
--- a/docs/architecture/psa-migration/strategy.md
+++ b/docs/architecture/psa-migration/strategy.md
@@ -42,7 +42,7 @@
- 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 @@
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 @@
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
=============================================================
diff --git a/docs/architecture/tls13-support.md b/docs/architecture/tls13-support.md
index 3154ac1..2cf2a48 100644
--- a/docs/architecture/tls13-support.md
+++ b/docs/architecture/tls13-support.md
@@ -324,7 +324,7 @@
```
- 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