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/3.0-migration-guide.md b/docs/3.0-migration-guide.md
index 12cff49..3653683 100644
--- a/docs/3.0-migration-guide.md
+++ b/docs/3.0-migration-guide.md
@@ -48,7 +48,7 @@
If you were accessing structure fields directly, and these fields are not documented as public, you need to change your code. If an accessor (getter/setter) function exists, use that. Direct accessor functions are usually called `mbedtls_<MODULE>_{get,set}_<FIELD>` or `mbedtls_<MODULE>_<STRUCTURE>_{get,set}_<FIELD>`. Accessor functions that change the format may use different verbs, for example `read`/`write` for functions that import/export data from/to a text or byte string.
-If no accessor function exists, please open an [enhancement request against Mbed TLS](https://github.com/ARMmbed/mbedtls/issues/new?template=feature_request.md) and describe your use case. The Mbed TLS development team is aware that some useful accessor functions are missing in the 3.0 release, and we expect to add them to the first minor release(s) (3.1, etc.).
+If no accessor function exists, please open an [enhancement request against Mbed TLS](https://github.com/Mbed-TLS/mbedtls/issues/new?template=feature_request.md) and describe your use case. The Mbed TLS development team is aware that some useful accessor functions are missing in the 3.0 release, and we expect to add them to the first minor release(s) (3.1, etc.).
As a last resort, you can access the field `foo` of a structure `bar` by writing `bar.MBEDTLS_PRIVATE(foo)`. Note that you do so at your own risk, since such code is likely to break in a future minor version of Mbed TLS.
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
diff --git a/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md b/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md
index 4f82bed..2a10ca0 100644
--- a/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md
+++ b/docs/proposed/psa-driver-wrappers-codegen-migration-guide.md
@@ -1,5 +1,5 @@
-Migrating to an auto genrated psa_crypto_driver_wrappers.c file
-===============================================================
+Migrating to an auto generated psa_crypto_driver_wrappers.c file
+================================================================
**This is a specification of work in progress. The implementation is not yet merged into Mbed TLS.**
@@ -8,7 +8,7 @@
## Introduction
-The design of the Driver Wrappers code generation is based on the design proposal https://github.com/ARMmbed/mbedtls/pull/5067
+The design of the Driver Wrappers code generation is based on the design proposal https://github.com/Mbed-TLS/mbedtls/pull/5067
During the process of implementation there might be minor variations wrt versioning and broader implementation specific ideas, but the design remains the same.
## Prerequisites