Appease the markdown linting gods

Fixed trailing whitespace, spaces around headings and lists, consistent lists

Signed-off-by: Patrick Smyth <patrick@iotaschool.com>

content/en/about/overview.md

@@ -16,19 +16,19 @@ It’s free to use for all developers and software providers, with Sigstore’s
 
 ## How to use Sigstore
 
-* I want to [Quick Start](/signing/quickstart/)
-* I want to [sign a blob](signing/signing_with_blobs/)
-* I want to [sign a container](signing/signing_with_containers/)
-* I want to [Sign Git commits with Gitsign](/signing/gitsign/)
-* I want to [verify entries with Cosign](/verifying/verify/)
+- I want to [Quick Start](/signing/quickstart/)
+- I want to [sign a blob](signing/signing_with_blobs/)
+- I want to [sign a container](signing/signing_with_containers/)
+- I want to [Sign Git commits with Gitsign](/signing/gitsign/)
+- I want to [verify entries with Cosign](/verifying/verify/)
 
 ## How Sigstore works
 
-A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity. 
+A Sigstore client, such as Cosign, requests a certificate from Fulcio, a code-signing certificate authority. A verifiable OpenID Connect identity token, which contains a user's email address or service account, is provided in the request. Fulcio verifies this token and issues a short-lived certificate bound to the provided identity.
 
 You don’t have to manage signing keys, and Sigstore services never obtain your private key. The public key that a Sigstore client creates gets bound to the issued certificate, and the private key is discarded after a single signing.
 
-After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified. 
+After the client signs the artifact, the artifact's digest, signature and certificate are persisted in Rekor, an immutable, append-only transparency ledger, so that signing events can be publicly audited. Identity owners can monitor the log to verify that their identity is being properly used. This also timestamps the signing event, so that the short-lived certificate can be later verified.
 
 For verifying an artifact, a Sigstore client will verify the signature on the artifact using the public key from the certificate, verify the identity in the certificate matches an expected identity, verify the certificate's signature using Sigstore's root of trust, and verify proof of inclusion in Rekor.
 
@@ -51,4 +51,4 @@ Ready to jump in? Check the [contributing guidelines](/about/contributing/).
 ## Learn more
 
 - [Sigstore YouTube Channel](https://www.youtube.com/@projectsigstore)
-- [Sigstore Blog](https://blog.sigstore.dev/) 
+- [Sigstore Blog](https://blog.sigstore.dev/)

content/en/about/security.md

@@ -10,24 +10,27 @@ The Sigstore security model has a few key components, each aimed at establishing
 
 ## Proving Identity in Sigstore
 
-Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio. 
+Sigstore relies on the widely used OpenID Connect (OIDC) protocol to prove identity. When running something like `cosign sign`, users will complete an OIDC flow and authenticate via an identity provider (GitHub, Google, etc.) to prove they are the owner of their account. Similarly, automated systems (like GitHub Actions) can use Workload Identity or [SPIFFE](https://spiffe.io/) Verifiable Identity Documents (SVIDs) to authenticate themselves via OIDC. The identity and issuer associated with the OIDC token is embedded in the short-lived certificate issued by Sigstore’s Certificate Authority, Fulcio.
 
 ## Sigstore’s Trust Model
 
-Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio. 
+Sigstore’s trust model originates from the Trust Root and chains down to short-lived certificates issued by Fulcio.
 
 ### Sigstore’s Trust Root
 
 The Trust Root, which was established during a public [root key signing ceremony](https://www.youtube.com/watch?v=GEuFsc8Zm9U), is made up of a rotation of five keyholders from varying companies and academic institutions who contribute to Sigstore. It leverages the principles of [The Update Framework](https://theupdateframework.io/) (TUF), a set of defined attacks and threat models specific to software distribution systems. TUF provides a cleverly designed set of protocols to protect against these types of attacks, which the Trust Root follows.
 
 The Sigstore Trust Root is used to secure the keys used by the entire Sigstore project. It allows individuals and systems to automatically retrieve trusted keys and certificates used to verify artifacts produced by the Sigstore ecosystem. Using the Sigstore Trust Root, end users can verify:
+
 * Certificates issued by Fulcio
 * Entries in the Rekor transparency log
+
 This allows end users to verify (and trust) that the distributors of the software they use are who they say they are.
 
 For more details on the Trust Root or the key signing ceremony, see [A New Kind of Trust Root](https://blog.sigstore.dev/a-new-kind-of-trust-root-f11eeeed92ef). For an overview of TUF, see [The Update Framework and You](https://blog.sigstore.dev/the-update-framework-and-you-2f5cbaa964d5).
 
 ### Rekor Security Model
+
 The Rekor service provides a transparency log of software signatures. The log is append-only and once entries are added they cannot be modified; a valid log can be cryptographically verified by any third-party. As entries are appended into this log, Rekor periodically signs the full [Merkle tree](https://transparency.dev) along with a timestamp.
 
 An entry in Rekor provides a single-party attestation that a piece of data existed prior to a certain time. These timestamps and the contents of the log cannot be tampered with or removed later, providing long-term trust. This long-term trust also requires that the log is monitored.