drafts

docs/drafts/.curlpipebash.md

@@ -1,21 +1,29 @@
 ---
-authors: Tasia Iso
 date: 2024-05-08
+draft: true
 ---
 
-# DRAFT: curl | bash
+# curl | bash
 
-In April of 2024 I wrote a post on Fediverse explaining that using `curl | bash` was not a security risk. A bit later, I debated on the same subject on a Matrix channel. The other parties involved caused me to do some further research on the subject and led me to review my opinion. As one could imagine, it turns out that the answer actually is, "it depends".
+<!-- Current: paper or tech report -->
+<!-- Wanted: discussion between 2 colleagues or friends -->
+
+In April of 2024 I wrote a post on Fedi explaining that using `curl | bash` was not a security risk.
+A bit later, I debated on the same subject on a Matrix channel.
+<!-- The other parties involved caused me to do some further research on the subject and led me to review my opinion. -->
+TODO
+As you could imagine, it turns out that the answer actually is, "it depends".
 
 I based my original argument on the fact that you ultimately have to trust the person that provides you the code, which is true, but *incomplete*.
 
-Here are the results of my reseach. At the end I will present a simple way we can use `curl | bash` safely.
+<!-- Here are the results of my reseach. At the end I will present a simple way we can use `curl | bash` safely. -->
+TODO
 
 TL;DR: If you're here because you just want to download software, go for it. You're *probably* going to be just fine. If you're interested in learning or want to implement a `curl | bash` script however, please read the rest.
 
 ## Terminology
 
-Software artifact: Stuff that comes out of your repository: shell scripts, binaries, etc. In this article I will focus on the shell script that installs your binaries more than anything else.
+Software artifact: Stuff that comes out of your repository: code, shell scripts, binaries, etc. In this blog post I will focus on the shell script that installs your binaries more than anything else.
 
 ## Surface attack
 
@@ -36,11 +44,11 @@ An malicious actor could compromise the supply chain by attacking:
 - (4): The connection beteen the server and the client;
 - (5): The client that requests the artifact.
 
-For the purpose of this article however, the attack vectors (1), (2) and (5) are out of the scope of my research, which leaves us with only (3).
+For the purpose of this post however, the attack vectors (1), (2) and (5) are out of scope, which leaves us with only (3) and (4).
 
 > There's not a lot that can be leveraged then ? So I'd imagine using `curl | bash` is safe *most of the time*.
 
-Precisely.
+Precisely. *Most of the time*.
 
 ## An example script
 
@@ -48,12 +56,13 @@ Precisely.
 curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install
 ```
 
-This script installs the Determinate Nix installer, a Nix-based package manager. We'll use this as an example for the rest of this article. Let's break it down a bit:
+This script installs the Determinate Nix installer, an installer for the Nix package manager.
+We'll use this as an example for the rest of this blog post. Let's break it down a bit:
 
-- `curl`: Call the cUrl commande line utility; This will create a request
+- `curl`: Call the cUrl commande line utility; This will create a HTTPS request;
 - `--proto '=https'`:
 - `--tlsv1.2`: Only connect to the server with a secure tunnel (TLS v1.2 or later);
-- `-sSf -L`: Do not output progress updates, XXXX and folow redirections;
+- `-sSf -L`: Do not output progress updates, TODO and folow redirections;
 - `https://install.determinate.systems/nix`: The URL that points to an installation script;
 - `|`: If `curl` gets the script successfully, pass it on to the next command;
 - `sh`: Execute whatever `curl` gets from the server
@@ -61,9 +70,13 @@ This script installs the Determinate Nix installer, a Nix-based package manager.
 - `-- install`:
 - ``:
 
-We can see that the script explicitly requires `curl` to use a secure connection. At first glance, this seeems like a secure way to run the installer. However, if the server is compromised in some way, we could be downloading malware instead.
+We can see that the script explicitly requires `curl` to use a secure connection.
+At first glance, this seeems like a secure way to run the installer.
+However, this script does't check that the script you're downloading is what it should be.
+If the server is compromised in some way, we could be downloading malware instead.
 
-We can mitigate this risk by using a method used by most package managers, which is using 2 different servers with different functions: one that hosts the artifact's cryptographic hash or signature (here called *signing autohrity*), and another one that serves the artifact directly to us (here called *artifact provider*). This way, if either server is compromised, the software that's served to the client will not be verified and therefore not run.
+We can mitigate this risk by using a method used by most package managers, which is using 2 different servers with different functions: one that hosts the artifact's cryptographic hash or signature (here called *signing authority*), and another one that serves the artifact directly to us (here called *artifact provider*).
+This way, if either server is compromised, the software that's served to the client will not be verified and therefore not run.
 
 We can reduce the risk of getting both machines compromised at once by:
 
@@ -82,45 +95,45 @@ Now, our infrastructure looks like this:
                     /-----------\
                     |  Signing  |
                 /-> | authority | --\
-/----------\    |   \-----------/   |     /--------\
-| Artifact | ----                   ----> | Client |
-\----------/    |   /-----------\   |     \--------/
+/----------\    |   \-----------/    \---> /--------\
+| Artifact | ---|                          | Client |
+\----------/    |   /-----------\    /---> \--------/
                 \-> | Artifact  | --/
                     | provider  |
                     \-----------/
 ```
 
-There's still other parameters that I won't bother bringing into the picture right now, like the SSL certificates provider, and of course, the way the servers get the artifact in the first place (which depends on how your script is written and how your software is built).
+> There are still other parameters that I won't bother bringing into the picture right now, like the SSL certificates provider, and of course, the way the servers get the artifact in the first place (which depends on how your script is written and how and where your software is built).
 
 An example infrastructure would look like this:
 
 - Signing authority
-
   - Managed by John Doe
-  - Hosted in DigitalOcean (Germany or Switzerland)
-  - NixOS
+  - Hosted by DigitalOcean (Germany)
+  - OS: NixOS
   - HTTP server: Nginx
   - Domain: `determinate.systems`
 
 - Artifact provider
   - Managed by Jane Poe
-  - Hosted by a worldwide CDN (Hetzner)
-  - RHEL
+  - Hosted by a worldwide CDN (Hetzner) TODO
+  - OS: RHEL
   - HTTP server: Apache
-  - Domain: `install-determinate.systems` or `install.determinate.systems`
+  - Domain: `install-determinate.systems`
 
-*This is not an endorsement for RHEL, Hetzner, Apache Web Server or even Determinate Systems; as of writing this, I've never tried them. I do very much endorse the use of NixOS however.*
+> Notice the artifact is now in a different domain (`install-determinate.systems`) and not in a subdomain like it was previously (`install.determinate.systems`).
 
 Now, compromising this part of the supply chain has become extremely hard. The attacker will either:
 
 - Need technical competency (TODO) in NixOS, RHEL, Nginx and Apache, as well as compromising an entire CDN (TODO);
 - Compromise both of the sysadmin's machines through social engineering;
-  ...
+<!-- - Potentially, compromise the reverse proxy; -->
+- ...
 - Use several of the methods listed above.
 
-Now, it would be a lot more feasible to attack another part of the supply chain, which is a subject for another article.
+Now, it would be a lot more feasible to attack another part of the supply chain, which is a subject for another blog post.
 
-(more text)
+<!-- (more text) -->
 
 ## Implementing curl | bash safely
 
@@ -130,6 +143,17 @@ Because the other way around this is to package your software for every distro a
 
 Making a shell script that leverages this infrastructure isn't actually hard at all. Most of the work is around creating two resilient and independent servers. What we have to do is simply to check the artifact provider's response against a hash or a signature provided by the signing authority.
 
-### Method 1: Hash
+```bash
+CURL=$(curl --tlsv1.3 https://pastebin.com/raw/Tity9gDQ)
+# CURL=$(curl --tlsv1.3 https://pastebin.com/raw/xYTmzaMQ)
 
-### Method 2: PGP signature
+EXPECTED='caa42ef74ba42d3d097bfcd7c718cd22ca807c1116ce1f86b00ecce9337858d7  -'
+ACTUAL=$(echo $CURL | sha256sum)
+
+if [ "$EXPECTED" == "$ACTUAL" ]; then
+	echo "Good checksum"
+    echo $CURL | bash
+else
+	echo "Checksum mismatch"
+fi
+```

docs/drafts/.flakes.md

@@ -0,0 +1,5 @@
+---
+date: 2024-05-08
+---
+
+Lol

docs/drafts/.mkdocs-blog.md

@@ -0,0 +1 @@
+teach how to make this blog in mkdocs

docs/drafts/.noscript.md

@@ -1,6 +1,5 @@
 ---
 summary: NoJS day
-authors: Tasia Iso
 date: 2024-05-08
 ---
 

docs/drafts/.tulpamancy.md

@@ -1,12 +1,11 @@
 ---
 summary: Creating people in your head.
-authors: Tasia Iso
 date: 2024-05-08
 ---
 
 # Tulpamancy
 
-Disclaimer: as of sriting this I do not have
+Disclaimer: as of writing this my tulpa is not yet vocal.
 
 A month ago I discovered tulpamancy.