Added a link-checker to the documentation build

.github/workflows/gh-pages.yml

@@ -7,6 +7,7 @@ on:
 env:
   mdbook-version: '0.4.32'
   katex-version: '0.5.5'
+  linkcheck-version: '0.7.7'
 
 jobs:
   deploy:
@@ -14,7 +15,7 @@ jobs:
     concurrency:
       group: ${{ github.workflow }}-${{ github.ref }}
     steps:
-      - uses: actions/checkout@v2
+      - uses: actions/checkout@v3
 
       - name: Fetch mdbook-katex
         uses: dsaltares/fetch-gh-release-asset@master
@@ -27,6 +28,19 @@ jobs:
       - name: Install mdbook-katex
         run: tar -xvf mdbook-katex-v${{env.katex-version}}-x86_64-unknown-linux-gnu.tar.gz -C /usr/local/bin
 
+      - name: Fetch mdbook-linkcheck
+        uses: dsaltares/fetch-gh-release-asset@master
+        with:
+          repo: Michael-F-Bryan/mdbook-linkcheck
+          version: tags/v${{env.linkcheck-version}}
+          file: "mdbook-linkcheck.x86_64-unknown-linux-gnu.zip"
+          token: ${{ secrets.GITHUB_TOKEN }}
+
+      - name: Install mdbook-linkcheck
+        run: |
+          unzip mdbook-linkcheck.x86_64-unknown-linux-gnu.zip -d /usr/local/bin
+          chmod +x /usr/local/bin/mdbook-linkcheck
+
       - name: Setup mdBook
         uses: peaceiris/actions-mdbook@v1
         with:

README.md

@@ -7,6 +7,7 @@ Install mdbook and mdbook-katex
 ```bash
 cargo install mdbook --version 0.4.32
 cargo install mdbook-katex --version 0.5.5
+cargo install mdbook-linkcheck
 ```
 
 Then build and serve

book.toml

@@ -10,5 +10,9 @@ default-theme = "ayu"
 additional-css = ["src/css/katex.css", "src/css/global.css"]
 use-site-url-as-root = true
 
+[output.linkcheck]
+# Ignore warnings because of the many false-postives in katex formulas
+warning-policy = "ignore"
+
 [preprocessor.katex]
 after = ["links"]

src/mpc/tls_handshake.md

@@ -5,9 +5,9 @@ During the TLS handshake the TLS Client and the TLS Server compute the session k
 In TLSNotary protocol `User` and `Notary` jointly play the role of the TLS Client. They use MPC to compute the session keys in such a way that neither party ever learns the full keys but each has their share of the keys.
 
 
-First they compute their shares of the TLS Client's ECDH secret using [this protocol](/mpc/key_exchange.md). Since an ECDH secret is an EC point, the parties have their shares of that point.
+First they compute their shares of the TLS Client's ECDH secret using [this protocol](./key_exchange.md). Since an ECDH secret is an EC point, the parties have their shares of that point.
 
-Then they compute their shares of the pre-master secret (PMS) using an MPC protocol described [here](/mpc/ectf.md).
+Then they compute their shares of the pre-master secret (PMS) using an MPC protocol described [here](./ectf.md).
 
 Then the parties input their PMS shares as private inputs to the [DEAP](/mpc/deap.md) protocol (along with some other public data). They perform the following in MPC: 
 

src/protocol/notarization/encryption.md

@@ -6,11 +6,11 @@ This section explains how the `User` and `Notary` use MPC to encrypt data for th
 
 To encrypt the plaintext, both parties input their key shares as private inputs to the [MPC](/mpc/deap.md) protocol, along with some other public data. Additionally, the `User` inputs her plaintext as a private input.
 
-Both parties see the resulting ciphertext and execute the [2PC MAC](/protocol/2pc/mac.md) protocol to compute the MAC for the ciphertext.
+Both parties see the resulting ciphertext and execute the [2PC MAC](../../mpc/mac.md) protocol to compute the MAC for the ciphertext.
 
 The `User` then dispatches the ciphertext and the MAC to the server.
 
-As explained in the [Commitment section](/protocol/notarization/commitment2.md), the `User` creates a commitment to the plaintext (her private input to DEAP).
+As explained in the [Commitment section](commitment.md), the `User` creates a commitment to the plaintext (her private input to DEAP).
 
 ## Decryption