docs(typos): fixing various typos found via vale.sh

src/docs/core-hashing.md

@@ -82,7 +82,7 @@ basically anywhere in the binary, but much like the Unix `strip`
 command, for the sake of simplicity and correctness, we move the
 section table to the back of the binary. Moreover, it would take
 significant additional work and require some storage to make this
-operation invertable.
+operation invertible.
 
 As a result, the Chalk Hash (the `HASH` metadata key), is not defined
 based on the file system hash. Instead, it is a _normalized_ hash,
@@ -104,8 +104,8 @@ artifacts must be semantically identical.
 
 ### More on The Chalk ID
 
-Once an artifact has been normalized, and the normalizated data stream
-has been hashed using SHA-256, we programiatically take 100 bits of
+Once an artifact has been normalized, and the normalized data stream
+has been hashed using SHA-256, we programmatically take 100 bits of
 the raw hash output, base-32 encode those bits, and then add some
 hyphens for clarity, to get the `CHALK_ID`.
 

src/docs/core-secret-manager-api.md

@@ -6,7 +6,7 @@ signing and attestation operations.
 
 All secrets and keying material are locally generated on the
 system running chalk, with the secret itself being encrypted
-locally priot to being sent to the API.
+locally prior to being sent to the API.
 
 This document provides an overview of the Secret Manager API, how
 data is stored securely, and how chalk interacts with the API as a
@@ -125,7 +125,7 @@ open source.
 The encryption scheme makes use of a PRP using the Luby-Rackoff
 construction. The easiest thing for us to do is to break the input
 into two 'halves',one being 128 bits (the width of AES, which we
-will call the 'lefthalf'), and the other the rest of the remaining
+will call the 'left half'), and the other the rest of the remaining
 width of the input (the 'right half').
 
 The nonce is random.
@@ -145,13 +145,13 @@ generate a key stream, that we XOR into the right half.
 The other PRF is HMAC-3. We take the round key, HMAC the right
 side, truncate the result to 128 bits, then XOR into the left half.
 
-The PRFs are used in a feistel cipher, so we alternate PRFs through
-our four feistel rounds.
+The PRFs are used in a Feistel cipher, so we alternate PRFs through
+our four Feistel rounds.
 
 While three-round Luby-Rackoff is secure against some use cases, we
 go through the full four rounds.
 
-PRPs are reversable, and with feistel contstructions, it's by
+PRPs are reversible, and with Feistel construction, it's by
 running the rounds backward.
 
 Once constructed it is this encrypted value that is sent to the

src/docs/guide-config-overview.md

@@ -32,7 +32,7 @@ The exact metadata that will be getting included in a report are defined in
 _templates_ which are simply collections of metadata keys (with optional conditions
 on when said metadata should be getting emitted). The same template
 can be re-used across many reports, however each of the different reports
-making use of the template could have different trigger/generation condidtions
+making use of the template could have different trigger/generation conditions
 and different destinations.
 
 Here is an excerpt from the template used by default for any metadata extracted
@@ -235,7 +235,7 @@ custom_report chalk_s3_logger {
 
 ```
 
-Notice that we have also suppreassed local terminal output for the above report.
+Notice that we have also suppressed local terminal output for the above report.
 
 ### Updating the used templates
 

src/docs/guide-getting-started.md

@@ -12,9 +12,9 @@ CI/CD pipeline. In many cases, it can be completely transparent to
 the user.
 
 Any configuration should be done up-front by whoever needs the data
-from chalk. While chalk is designed to be deeply customisable, we also
+from chalk. While chalk is designed to be deeply customizable, we also
 worked hard to make out-of-the-box configurations useful, and to make
-it very easy to configure common usecases.
+it very easy to configure common use-cases.
 
 First, let's do some basics to get up and running, both with
 chalking artifacts, and reporting on them in production.
@@ -239,7 +239,7 @@ to note for now:
 
 1. We've captured basic information about the build environment,
    including our repo, branch and commit ID. If you pull a repo remotely
-   from Github or Gitlab, the "ORIGIN_URI" key will give the URL where
+   from GitHub or GitLab, the "ORIGIN_URI" key will give the URL where
    the repository is hosted, instead of `local`.
 
 2. In addition to the report, we inserted a JSON blob into our
@@ -583,7 +583,7 @@ without specifying a file name (which will just print to stdout):
 chalk dump
 ```
 
-Youu should see:
+You should see:
 
 ```bash
 # The default config is empty. Please see chalk documentation for examples.
@@ -751,7 +751,7 @@ code you're running.
 
 Chalk really only monitors a subset of docker commands, but when
 wrapping docker, it will pass through all docker commands even if it
-doesn't do any of its own processing on them. If chalk encoounters an
+doesn't do any of its own processing on them. If chalk encounters an
 error while attempting to wrap docker, it will then execute the
 underlying docker command without chalk so that this doesn't break any
 pre-existing pipelines.
@@ -820,7 +820,7 @@ curl http://127.0.0.1:8585/execs
 # for pretty json output if you have jq installed, run `curl http://127.0.0.1:8585/execs | jq`
 ```
 
-![serverout](./img/execout.png){ loading=lazy }
+![exec output](./img/execout.png){ loading=lazy }
 
 You can see that, in addition to artifact information, there is also
 information about the operating environment, including the container

src/docs/guide-heartbeat.md

@@ -8,7 +8,7 @@
 
 This document is a guide on how to configure chalk so that a chalked binary or docker container emits a snapshot of network connections at set intervals.
 
-### Prerequisities
+### Prerequisites
 
 - chalk binary
 - (optional) dockerfile for a docker image with compatible architecture