backport of commit 4c9fc89d0d (#27115)

Co-authored-by: Martin Atkins <mart@degeneration.co.uk>

website/docs/commands/providers/lock.html.md

@@ -25,11 +25,11 @@ automatic approach may not be sufficient:
   be able to populate all of the possible package checksums for the selected
   provider versions.
 
-  If you use `terraform lock` to write the official release checksums for a
-  provider into the dependency lock file then future `terraform init` runs
-  will verify the packages available in your selected mirror against the
-  official checksums previously recorded, giving additional certainty that
-  the mirror is serving the provider packages it is claiming to.
+    If you use `terraform lock` to write the official release checksums for a
+    provider into the dependency lock file then future `terraform init` runs
+    will verify the packages available in your selected mirror against the
+    official checksums previously recorded, giving additional certainty that
+    the mirror is serving the provider packages it is claiming to.
 
 * If your team runs Terraform across a number of different platforms (e.g.
   on both Windows and Linux) and the upstream registry for a provider is unable
@@ -81,14 +81,14 @@ You can customize the default behavior using the following additional option:
   available for the given platform and will save enough package checksums in
   the lock file to support _at least_ the specified platforms.
   
-  Use this option multiple times to include checksums for multiple target
-  systems.
+    Use this option multiple times to include checksums for multiple target
+    systems.
 
-  Target platform names consist of an operating system and a CPU
-  architecture. For example, `linux_amd64` selects the Linux operating system
-  running on an AMD64 or x86_64 CPU.
+    Target platform names consist of an operating system and a CPU
+    architecture. For example, `linux_amd64` selects the Linux operating system
+    running on an AMD64 or x86_64 CPU.
 
-  There is more detail on this option in the following section.
+    There is more detail on this option in the following section.
 
 ## Specifying Target Platforms
 

website/docs/configuration/dependency-lock.html.md

@@ -123,12 +123,12 @@ There are two special considerations with the "trust on first use" model:
   your current platform _and_ any other packages that might be available for
   other platforms.
 
-  In this case, the `terraform init` output will include the fingerprint of
-  the key that signed the checksums, with a message like
-  `(signed by a HashiCorp partner, key ID DC9FC6B1FCE47986)`. You may wish to
-  confirm that you trust the holder of the given key before committing the
-  lock file containing the signed checksums, or to retrieve and verify the
-  full set of available packages for the given provider version.
+    In this case, the `terraform init` output will include the fingerprint of
+    the key that signed the checksums, with a message like
+    `(signed by a HashiCorp partner, key ID DC9FC6B1FCE47986)`. You may wish to
+    confirm that you trust the holder of the given key before committing the
+    lock file containing the signed checksums, or to retrieve and verify the
+    full set of available packages for the given provider version.
 
 * If you install a provider for the first time using an alternative
   installation method, such as a filesystem or network mirror, Terraform will
@@ -137,12 +137,12 @@ There are two special considerations with the "trust on first use" model:
   for other platforms and so the configuration will not be usable on any other
   platform.
 
-  To avoid this problem you can pre-populate checksums for a variety of
-  different platforms in your lock file using
-  [the `terraform providers lock` command](/docs/commands/providers/lock.html),
-  which will then allow future calls to `terraform init` to verify that the
-  packages available in your chosen mirror match the official packages from
-  the provider's origin registry.
+    To avoid this problem you can pre-populate checksums for a variety of
+    different platforms in your lock file using
+    [the `terraform providers lock` command](/docs/commands/providers/lock.html),
+    which will then allow future calls to `terraform init` to verify that the
+    packages available in your chosen mirror match the official packages from
+    the provider's origin registry.
 
 ## Understanding Lock File Changes
 
@@ -300,27 +300,27 @@ The two hashing schemes currently supported are:
   part of the Terraform provider registry protocol and is therefore used for
   providers that you install directly from an origin registry.
 
-  This hashing scheme captures a SHA256 hash of each of the official `.zip`
-  packages indexed in the origin registry. This is an effective scheme for
-  verifying the official release packages when installed from a registry, but
-  it's not suitable for verifying packages that come from other
-  [provider installation methods](/docs/commands/cli-config.html#provider-installation),
-  such as filesystem mirrors using the unpacked directory layout.
+    This hashing scheme captures a SHA256 hash of each of the official `.zip`
+    packages indexed in the origin registry. This is an effective scheme for
+    verifying the official release packages when installed from a registry, but
+    it's not suitable for verifying packages that come from other
+    [provider installation methods](/docs/commands/cli-config.html#provider-installation),
+    such as filesystem mirrors using the unpacked directory layout.
 
 * `h1:`: a mnemonic for "hash scheme 1", which is the current preferred hashing
   scheme.
 
-  Hash scheme 1 is also a SHA256 hash, but is one computed from the _contents_
-  of the provider distribution package, rather than of the `.zip` archive
-  it's contained within. This scheme therefore has the advantage that it can
-  be calculated for an official `.zip` file, an unpacked directory with the
-  same contents, or a recompressed `.zip` file which contains the same files
-  but potentially different metadata or compression schemes.
-
-  Due to the limited scope of the `zh:` scheme, Terraform will
-  opportunistically add in the corresponding `h1:` checksums as it learns
-  of them, which is what caused the addition of a second `h1:` checksum
-  in the example change shown above.
+    Hash scheme 1 is also a SHA256 hash, but is one computed from the _contents_
+    of the provider distribution package, rather than of the `.zip` archive
+    it's contained within. This scheme therefore has the advantage that it can
+    be calculated for an official `.zip` file, an unpacked directory with the
+    same contents, or a recompressed `.zip` file which contains the same files
+    but potentially different metadata or compression schemes.
+
+    Due to the limited scope of the `zh:` scheme, Terraform will
+    opportunistically add in the corresponding `h1:` checksums as it learns
+    of them, which is what caused the addition of a second `h1:` checksum
+    in the example change shown above.
 
 Terraform will add a new hash to an existing provider only if the hash is
 calculated from a package that _also_ matches one of the existing hashes. In