a

docs/drafts/.curlpipebash.md

@@ -1,5 +1,7 @@
 # DRAFT: curl | bash
 
+2024-05-08
+
 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".
 
 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*.
@@ -61,6 +63,7 @@ We can see that the script explicitly requires `curl` to use a secure connection
 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 reduce the risk of getting both machines compromised at once by:
+
 - Having them be controlled by 2 different entities (companies and/or persons);
 - Having them be managed by 2 different systems administrators;
 - Using different data centers, network routes, domains and SSL certificates;
@@ -89,6 +92,7 @@ There's still other parameters that I won't bother bringing into the picture rig
 An example infrastructure would look like this:
 
 - Signing authority
+
   - Managed by John Doe
   - Hosted in DigitalOcean (Germany or Switzerland)
   - NixOS
@@ -105,6 +109,7 @@ An example infrastructure would look like this:
 *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.*
 
 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;
   ...
@@ -124,8 +129,4 @@ Making a shell script that leverages this infrastructure isn't actually hard at
 
 ### Method 1: Hash
 
-
-
 ### Method 2: PGP signature
-
-

docs/drafts/.noscript.md

@@ -0,0 +1,5 @@
+# Disabling JavaScirpt
+
+2024-05-08
+
+A bit ago I found this article where a person didsabled JavaScript on their browser by default

docs/drafts/.tulpamancy.md

@@ -1,5 +1,7 @@
 # Tulpamancy
 
+2024-05-08
+
 Disclaimer: as of sriting this I do not have
 
 A month ago I discovered tulpamancy.

theme/main.html

@@ -81,10 +81,14 @@
       ><img src="images/badges/nixos.png" alt="nixos badge"
     /></a>
 
+    <a href="images/badges/credits.txt">(credits)</a>
 
-    <hr>
+    <hr />
-    This is a <a href="https://https://motherfuckingwebsite.com">motherfucking website</a>.
+    This is a
-    <br>
+    <a href="https://https://motherfuckingwebsite.com">motherfucking website</a
-    Built by <a href="https://www.mkdocs.org">mkdocs</a> and served by <a href="https://tilde.club">tilde.club</a>.
+    >.
+    <br />
+    Built by <a href="https://www.mkdocs.org">mkdocs</a> and served by
+    <a href="https://tilde.club">tilde.club</a>.
   </body>
 </html>