Fix after RC5 (#47)

Author: FaustXVI

example/docs/offline_vault_ceremony.md

@@ -81,8 +81,18 @@ The 📢`organiser` asks all `share holders` (including 👥`team members`) to c
 
 > [!Tip]  
 > The public key can be checked with the corresponding hardware token plugged in and with the public key imported in gpg.\
-> For this, enter the following command:\
-> `echo "It works" | gpg -e -f /path/to/public/key.pub | gpg -d`
+> For this, enter the following commands with the correct path to the keys :
+```
+export GPG_HW_TOKEN_KEY_ID=$(gpg --card-status | sed -n -E -e 's/^[^:]*sign[^:]*:[[:blank:]]*((:?[[:xdigit:]]{4}[[:blank:]]*){10})/\1/pi') && echo "$GPG_HW_TOKEN_KEY_ID"
+export TMP_GPG_HOME=$(mktemp -d)
+cp ~/.gnupg/*.conf "$TMP_GPG_HOME"/
+##############
+# Configure the next line
+##############
+gpg --home="$TMP_GPG_HOME" --import /path/to/share_holders_keys/env/*
+gpg --home="$TMP_GPG_HOME" --list-keys --keyid-format LONG --with-colons | sed -n -e '/^pub/{n;p}' | sed -n -E 's/^fpr:([^:]*:){8}([^:]*).*$/\2:6:/p' | gpg --home="$TMP_GPG_HOME" --import-ownertrust
+echo "It works" | gpg --home="$TMP_GPG_HOME" -e -r "$GPG_HW_TOKEN_KEY_ID" | gpg -d
+```
 
 #### Setting up the trusted commit
 
@@ -111,9 +121,7 @@ Get the last report for the corresponding environment and verify the signatures
 A gpg-based one can be found in [the O.R.CA documentation](https://eove.github.io/orca/unstable/signing_and_verifying.html)
 
 > [!Warning]  
-> All signatures should be valid. The check above should be valid for at least the 3 👥`team members` of the previous ceremony.
->
-> Only **one** invalid/missing signature is enough to **stop the ceremony**. In such a case, the issue should be analysed.
+> **Any** invalid/missing/incomplete signature is enough to **stop the ceremony**. In such a case, the issue should be analysed.
 
 Once all signatures has been verified, to get ready for subsequent steps, extract from the `previous ceremony report`:
  - the `trusted commit` that was used back then (that we will refer to as `previous trusted commit`)
@@ -243,7 +251,7 @@ These 3 persons should be **physically present during the whole ceremony**, and
 
 > [!Tip]
 > To extract these sections from the html version of the ceremony's workflow, use the following filter:\
->  `cat /path/to/ceremory_workflow.html | sed -e 's|<\([/]\)*code class="language-report">|\n<\1\@ORCA\@report\@>\n|g' | sed -n -e '/<\@ORCA\@report\@>/,/<\/\@ORCA\@report\@>/{s/<[/]*\@ORCA\@report\@>//;p}' | tee /tmp/blank_report.txt`
+>  `cat /path/to/ceremony_workflow.html | sed -e 's|<\([/]\)*code class="language-report">|\n<\1\@ORCA\@report\@>\n|g' | sed -n -e '/<\@ORCA\@report\@>/,/<\/\@ORCA\@report\@>/{s/<[/]*\@ORCA\@report\@>//;p}' | tee /tmp/blank_report.txt`
 
 3. The third role is the `observer` (👀).\
    This person should be [randomly](https://www.random.org/lists/) picked among all share holders except the two other 👥`team members`. The random draw will be performed by either the 💻`operator` or 📝`reporter`.\
@@ -260,6 +268,9 @@ These 3 persons should be **physically present during the whole ceremony**, and
 
 For the rest of the procedure below, you can consider references to 👥`team members` as a synonym for the group of the 3 roles above.
 
+> [!Warning]
+> The 👀`observer` will have to access the keyboard to give sudo access during the checks. The other 👥`team members` should be able to keep an eye on the USB stick while not seeing the keyboard at that moment.
+
 > [!Important]  
 > In the report below, and only when initializing the vault the first time, a few `FAIL`ed items are expected.\
 > They are identified with a star in the report like this `FAIL* []`

example/docs/periodical_checks.md

@@ -40,7 +40,7 @@ If a word used in this document is unknown to you, the [O.R.CA documentation con
 In order to execute the current document, you will need:
 * An initialised offline vault
 * An initialised and running online vault
-* To fulfill all the prerequisites to run an ceremony
+* To fulfill all the prerequisites to run a ceremony
 
 ## Recurrent checks
 
@@ -50,7 +50,7 @@ Checks (and fixes) below should be performed first on the preprod environment, t
 If fixes are needed, this means running a ceremony on preprod, and then a ceremony on prod.
 
 > [!Warning]  
-> In order to run scripts on the offline vault, samples files are provided in the `actions` directory. You should adapt these scripts to your need, then commit to git. Only then, will the live bootable media contain the updated version of these scripts.
+> In order to run scripts on the offline vault, samples files are provided in the `actions` directory. You should adapt these scripts to your needs, then commit to git. Only then, will the live bootable media contain the updated version of these scripts.
 
 ### Hardware token's certificates that have expired should be renewed
 
@@ -72,7 +72,7 @@ This is especially important because, when initially generating certificates on
 
 #### Test
 
-Hardware token's certificates expire on 30/12 of the year mentioned in their public key filename (as registered in the folder `share_holders/`)
+Hardware token's certificates expire on 30/12 of the year mentioned in their public key filename (as registered in the folder `share_holders/`).
 If a hardware token certificate is expired when performing this check, then it should be renewed.
 
 The 📢`organiser` should perform this check and ask the relevant share holders to renew their hardware token's GPG key pair.
@@ -93,7 +93,7 @@ An unseal share rotation should be run also on the online vault.
 
 ### Every share holder have and can use their hardware token's GPG key
 
-Every share holder should have a hardware token and should have a GPG public key registered in the folder `share_holders/`
+Every share holder should have a hardware token and should have a GPG public key registered in the folder `share_holders/`.
 These hardware token's GPG keys' details should match their owner's name and e-mail address at the company.
 
 Every share holder runs the following tests.
@@ -175,7 +175,7 @@ The start of validity date will be called *D<sub>start</sub>*, it can be found i
 The expiry date will be called *D<sub>expiry</sub>*, it can be found in the `Validity`'s `Not After` attribute displayed by the command above.
 
 The following statement should be true:
-*D<sub>start</sub>*<*D<sub>now</sub>* **and** *D<sub>expiry</sub>*>*D<sub>min</sub>*.
+*D<sub>start</sub>*<*D<sub>now</sub>* **and** *D<sub>min</sub>*<*D<sub>expiry</sub>*.
 If this is the case, this test is a PASS.  
 If not, a new online CA should be generated, the fix below should be applied.
 
@@ -286,7 +286,7 @@ exit -42
 > This means that, if that script succeeds, you can trust that CSR.
 > However, if it fails, then it can either be a wrong CSR **or** a change in vault. Please check accordingly.
 
-Once the check have been performed, a ceremony is executed on the offline CA and the CSR is signed, we should get a certificate chain output PEM file, let's store it into `/tmp/online_cert.pem`.
+Once the check has been performed, a ceremony is executed on the offline CA and the CSR is signed, we should get a certificate chain output PEM file, let's store it into `/tmp/online_cert.pem`.
 We now have to import that certificate in the **online vault**.
 
 Once this has been done, in order to be sure that the imported certificate corresponds to a CSR generated by the online vault, please make sure that the current **default** issuer ID for the devices PKI has changed from the value you initially wrote down above:
@@ -338,20 +338,20 @@ You have two options there:
 - Either the current offline root CA can be rotated (see [Vault's documentation](https://developer.hashicorp.com/vault/tutorials/pki/pki-engine#step-7-rotate-root-ca))\
   This requires writing scripts for this to be run on the offline *ephemeral vault*.
 - Or you can create a brand new offline root CA.\
-  This would be a brand new start of the root CA and this means re-initializing a new vault, start from an empty backup etc.\
+  This would be a brand new start of the root CA and this means re-initialising a new vault, start from an empty backup etc.\
   Please read [the documentation on how to setup a new PKI](https://eove.github.io/orca/unstable/pki_init.html).
 
 > [!Note]  
-> In any case, the old PKI (and offline CAs) are still valid for at least 6 months, so you can use them up to the end of their validity. After their validity has elapsed, the expired CAs should be kept as read-only and won't be used anymore (except if revokation is required).
+> In any case, the old PKI (and offline CAs) are still valid for at least 6 months, so you can use them up to the end of their validity. After their validity has elapsed, the expired CAs should be kept as read-only and won't be used anymore (except if revocation is required).
 
 > [!Tip]  
 > When renewing the root CA, you may as well evaluate the following aspects:
 > - is the crypto used for the trust chain still up-to-date or should it be updated?
 > - is hashicorp vault and upstream O.R.CA version (used as a template) still up-to-date and maintained, in general and in NixOS or should the PKI be setup using new tools?
-> - the environment in which the vault has been created initially has been progressively migrated from an initialization state 30 years before, it's maybe time to clean-up and start from scratch.
+> - the environment in which the vault has been created initially has been progressively migrated from an initialisation state 30 years before, it's maybe time to clean-up and start from scratch.
 > - restarting from scratch allows to detach the currently active PKI from all history of previously chained reports and audit trails.
 > - we may want to start with better security ecosystem (better crypto, improved initialisation in both hashicorp vault and our own scripts) after 30 years, it's probably time to review the whole setup in depth, including scripts, hashicorp vault, tools (hardware tokens, NixOS bootable media), and where and how backups+reports are saved.
-> - after 30 years, it would be good to get new people own the whole system, including setup from scratch
+> - after 30 years, it would be good to get new people to own the whole system, including setup from scratch
 > - you have 6 months...
 
 ### The next periodical check is planned

example/orca-config.nix

@@ -4,6 +4,10 @@
   rotate_keys = false;
   actions_folder = ./actions;
   share_holder_keys_folder = ./share_holders_keys;
+  xkb = {
+    layout = "fr,fr,us";
+    variant = "oss,bepo,";
+  };
   actions_in_order = [
     #"create-root-CA"
     #"create-intermediate-CA"

src/orca-nixos-module.nix

@@ -98,6 +98,16 @@
             type = types.ints.positive;
             default = 3;
           };
+          xkb = {
+            layout = mkOption {
+              type = types.str;
+              default = "us";
+            };
+            variant = mkOption {
+              type = types.str;
+              default = "";
+            };
+          };
           actions_folder = mkOption {
             type = types.path;
           };
@@ -225,11 +235,9 @@ If it should indeed be allowed to run as root, please double check them for secu
             autologinUser = orca_user.name;
             autologinOnce = true;
           };
-          xserver.xkb = {
-            layout = "fr,fr,us";
-            variant = "oss,bepo,";
+          xserver.xkb = config.orca.xkb // ({
             options = "grp:menu_toggle";
-          };
+          });
           # Configure vault
           vault = {
             enable = true;

testing/orca-config.nix

@@ -13,4 +13,8 @@
   vm = {
     root_public_key = ./root_key.pub;
   };
+  xkb = {
+    layout = "fr,fr,us";
+    variant = "oss,bepo,";
+  };
 }