include some graphs

make speaker notes more legible, update for marp 4.0.0
updates
2024-10-08 15:54:37 -04:00 · 2024-10-08 13:36:08 -04:00 · 2024-09-18 11:49:35 -04:00 · 2024-08-21 13:22:55 -04:00 · 2024-08-20 19:00:12 -04:00
15 changed files with 15 additions and 836 deletions
--- a/README.md
+++ b/README.md
@ -2,6 +2,5 @@
 ## Instructions
-1. Install [`marp-cli`](https://github.com/marp-team/marp-cli)
+1. Install [`marp-cli`](#stagex:matrix.org)
-2. Run `marp <file.md>` to create an html file
+2. Run `marp <md_file.md>` to create an html file
 3. Open file using browser
--- a/openpgp-workshop/img/diffie-helman.png
+++ b/openpgp-workshop/img/diffie-helman.png
--- a/openpgp-workshop/img/encrypt-decrypt.png
+++ b/openpgp-workshop/img/encrypt-decrypt.png
--- a/openpgp-workshop/img/iceberg.jpg
+++ b/openpgp-workshop/img/iceberg.jpg
--- a/openpgp-workshop/img/iceberg.png
+++ b/openpgp-workshop/img/iceberg.png
--- a/openpgp-workshop/img/sign-verify.png
+++ b/openpgp-workshop/img/sign-verify.png
--- a/openpgp-workshop/index.md
+++ b/openpgp-workshop/index.md
@ -1,240 +0,0 @@
 # OpenPGP Workshop
 [important reference](img/iceberg.png)
 ---
 ## What is OpenPGP
 * OpenPGP is an open standard for encrypting and decrypting data, as well as
 creating and managing digital signatures.
 * It is based on the PGP (Pretty Good Privacy) protocol, which was originally
 developed by Phil Zimmermann in the 1990s.
 * Uses asymmetric / public key cryptography
 <!--
 What are some useful ways we can use OpenPGP:
    * Email encryption and signing
    * Signing git commits
    * SSH
    * Password management
 -->
 ---
 ## Implementations
 * GPG
    * Gnu Privacy Guard
    * Best known and most widely used
    * Great starting point
 * There are lots of other implementations of OpenPGP:
    * https://www.openpgp.org/software/developer/
 ---
 ## How Does It Work?
 ---
 ## Encrypt / Decrypt
 ![Encryption vs Decryption diagram](img/encrypt-decrypt.png)
 ---
 ## Sign / Verify
 ![Signing vs Verifying diagram](img/sign-verify.png)
 ---
 ## Diffie Helman Key Exchange
 ![Diffie Helman Key Exchange diagram](img/diffie-helman.png)
 ---
 ## OpenPGP Anatomy
 * Many components but key ones are:
    * Public Key
    * Private Key
 ---
 ## Let's Try It!
 * Most OS come with GPG pre-installed (not Windows!)
 * `gpg --version`
 * `man gpg`
 * **THESE FOLLOWING KEYS WILL NOT BE SECURE, DO NOT USE THEM FOR ANYTHING OTHER THAN THIS EXERCISE!**
 * Generate keypair: `gpg --expert --full-gen-key`
    * 1, 4096, Enter (3072), Enter (0), y, "Test Key", <your_email>, Enter (""), O, "password1"
    * Use a unique email otherwise you will have issues with the exercise that follows
    * During generation, **mash input devices for added entropy**
 ---
 ## Test Your GPG Key
 * `gpg --list-keys`
 * `echo "super secret text" > test.txt && cat test.txt`
 * `gpg --encrypt --recipient <email/ID> test.txt`
 	* `gpg -er <email/ID> <filename> && cat test.txt.gpg`: notice it's a binary
 	    * You can use `--armor/-a` to encode it as ASCII so you can send the encrypted data as text
 * `gpg --armor -er <email/ID> test.txt && cat test.txt.asc`
 * `rm test.txt && ls`
 * `gpg --decrypt test.txt.gpg > test.txt`
 * `gpg --decrypt test.txt.asc > test.txt`
 ---
 ## Sharing Your Public Key 🔑
 * `gpg --list-keys`
 * `gpg --export --armor <email/ID> > <name>.asc`
 * `gpg --import <name>.asc`
 * Task: pair up and exchange your keys, encrypt data to each other, then decrypt the message so you can tell your partner the contents of the message
    * Tip: you may encrypt the data to multiple people
 ---
 ## Verifying Signatures 📝
 * Go to: https://www.qubes-os.org/downloads/
 * Download:
    * Qubes-R*.iso
    * Cryptographic hash values
    	* `gpg --verify --default-key <key> <filename>`
    * Detached PGP signature
    * Qubes release signing key
 * They have a guide that's worth reading: https://www.qubes-os.org/security/verifying-signatures/
 * Task: verify the signatures for the software are valid
 ---
 ## Solution
 * `gpg --import qubes-release-*`: import qubes signing key
 * `gpg --verify *.DIGESTS`: verify signature
 * `sha256sum -c Qubes-<...>.iso.DIGESTS`: verify hashes match
 ---
 ## Secure Key Management 🔒
 * You should assume your computer is compromised
 * How do we protect the GPG private key?
    * Never expose them to an untrusted environment
 ---
 ## Basic: On-board generation:
 * YubiKey offers generating keys inside of the YubiKey
 * Cryptographic attestation keys were never exposed available: https://developers.yubico.com/PGP/Attestation.html
 * CON: can't back up the keys
 * PRO: simple setup
 ---
 ## Advanced - cold / virtualization
 * Can use `gpg` / `sq` / `keyfork` to derive
 * Key is to derive keys in a secure environment:
    * Airgapped system (preferred)
        * [AirgapOS](https://git.distrust.co/public/airgap): A full-source-bootstrapped, deterministic, minimal, immutable, and offline, workstation linux distribution designed for creating and managing secrets offline.
    * Virtual machine on a hypervisor via hardware virtualization (ok for some threat models)
 * [Hashbang GPG Guide](https://book.hashbang.sh/docs/security/key-management/gnupg/): helpful guide for GPG - good resource for beginners who want to do the advanced setup
 * [openpgp-card-tools](https://codeberg.org/openpgp-card/openpgp-card-tools): great for loading keys onto smart cards
    * Can use a variety of smart cards: NitroKey3, SoloKey, Yubikey
        * NitroKey and SoloKey are fully open which is great for verifiability - may requires flashing firmware
 * [Quorum Key Management](https://docs.distrust.co/qkm/)
 ---
 ## Backup Trick 🧙
 * Generate long lived keys
 * Load them onto smart card
 * Take plaintext key data and put it in a dir
 * Encrypt the dir to your public key
 * Delete keys so that only ones that remain are on smart cards (recommended to have at least 2 or 3, for redundancy)
 * Smart cards have a "brick" after x attempts feature
 ---
 ## SSH Usage
 * OpenPGP keys can be used for SSH as well 🪄:
    * `gpg --export-ssh-key <email/keyID>`
 * Set up shell to use smart card for ssh:
    ```
    # always use smart card for ssh
    unset SSH_AGENT_PID
    if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then
        export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)"
    fi
    ```
 ---
 ## Git Usage
 * You can sign commits using OpenPGP / GPG
    ```~/.bashrc
    GPG_TTY=$(tty)
    export GPG_TTY
    ```
    ```~/.gitconfig
    [user]
        email = <email>
        name = <name>
        signingKey = <key_id>
    [commit]
        gpgSign = true
    [merge]
        gpgSign = true
    [gpg]
        program = gpg
    ```
 ---
 ## Further Studies
 * [keyoxide](https://keyoxide.org/): decentralized tool to create and verify decentralized online identities
 * [pass](https://www.passwordstore.org/): Unix based `gpg` password manager
 * [OpenPGP for application developers](https://openpgp.dev/book/): Deep dive on OpenPGP
 * [Sequoia](https://sequoia-pgp.org/): alternate OpenPGP implementation in rust
 * [openpgp-card](https://codeberg.org/openpgp-card)
    * [openpgp-card-tools](https://codeberg.org/openpgp-card/openpgp-card-tools)
    * [ssh-agent](https://codeberg.org/openpgp-card/ssh-agent)
 ---
 # Cleanup
 * `gpg --delete-secret-and-public-keys <key_id>`
--- a/stagex/demo-auto.cast
+++ b/stagex/demo-auto.cast
@ -1,49 +0,0 @@
 {"version": 2, "width": 63, "height": 15, "timestamp": 1729797434, "env": {"SHELL": "/usr/bin/zsh", "TERM": "screen-256color"}}
 [0.090248, "o", "Sending build context to Docker daemon  557.1kB\r"]
 [0.093028, "o", "Sending build context to Docker daemon  1.037MB\r\r\r\n"]
 [0.100052, "o", "Step 1/27 : FROM scratch AS libfakerand\r\n ---> \r\nStep 2/27 : COPY --from=stagex/busybox . /\r\n"]
 [0.326734, "o", " ---> edd79937efa6\r\nStep 3/27 : COPY --from=stagex/rust . /\r\n"]
 [3.478221, "o", " ---> 35b5a434bf39\r\nStep 4/27 : COPY --from=stagex/musl . /\r\n"]
 [4.308798, "o", " ---> 8d65fe22c193\r\nStep 5/27 : COPY --from=stagex/gcc . /\r\n"]
 [7.231311, "o", " ---> f46a59e4564b\r\nStep 6/27 : COPY --from=stagex/llvm . /\r\n"]
 [15.022258, "o", " ---> d5f07172a03e\r\nStep 7/27 : COPY --from=stagex/binutils . /\r\n"]
 [17.816179, "o", " ---> 1446a550e47e\r\nStep 8/27 : COPY --from=stagex/libunwind . /\r\n"]
 [18.026051, "o", " ---> b3a28fc5dea5\r\nStep 9/27 : COPY --from=stagex/git . /\r\n"]
 [19.450747, "o", " ---> 7c84e6add4fd\r\nStep 10/27 : COPY --from=stagex/openssl . /\r\n"]
 [24.905698, "o", " ---> 05e936ce8fcc\r\nStep 11/27 : COPY --from=stagex/zlib . /\r\n"]
 [25.316081, "o", " ---> bfc560e9b56c\r\nStep 12/27 : COPY --from=stagex/curl . /\r\n"]
 [25.711448, "o", " ---> ba0ba47e7082\r\nStep 13/27 : COPY --from=stagex/ca-certificates . /\r\n"]
 [25.948894, "o", " ---> 3e514bf61f14\r\nStep 14/27 : RUN git clone https://git.distrust.co/public/libfakerand /libfakerand\r\n"]
 [25.996504, "o", " ---> Running in 64b239021be1\r\n"]
 [26.25651, "o", "\u001b[91mCloning into '/libfakerand'...\r\n\u001b[0m"]
 [27.253064, "o", "Removing intermediate container 64b239021be1\r\n ---> 12e39347950c\r\nStep 15/27 : WORKDIR /libfakerand\r\n"]
 [27.306275, "o", " ---> Running in 81ef320df04c\r\n"]
 [27.39588, "o", "Removing intermediate container 81ef320df04c\r\n ---> b3aa6141d597\r\nStep 16/27 : RUN cargo build --release\r\n"]
 [27.42789, "o", " ---> Running in efc23d84c13e\r\n"]
 [27.865516, "o", "\u001b[91m    Updating crates.io index\r\n\u001b[0m"]
 [28.438381, "o", "\u001b[91m Downloading crates ...\r\n\u001b[0m"]
 [29.195025, "o", "\u001b[91m  Downloaded libc v0.2.155\r\n\u001b[0m"]
 [29.297817, "o", "\u001b[91m   Compiling libc v0.2.155\r\n\u001b[0m"]
 [30.795761, "o", "\u001b[91m   Compiling fakerand v0.1.0 (/libfakerand)\r\n\u001b[0m"]
 [31.181977, "o", "\u001b[91m    Finished `release` profile [optimized] target(s) in 3.48s\r\n\u001b[0m"]
 [31.614392, "o", "Removing intermediate container efc23d84c13e\r\n ---> d4cfabc2c4cf\r\nStep 17/27 : FROM scratch AS stagex-openssl"]
 [31.614434, "o", "\r\n ---> \r\nStep 18/27 : COPY --from=stagex/libunwind . /"]
 [31.614473, "o", "\r\n"]
 [31.620488, "o", " ---> Using cache\r\n"]
 [31.633181, "o", " ---> 3895b7cdfa39\r\nStep 19/27 : COPY --from=stagex/gcc . /\r\n"]
 [31.634595, "o", " ---> Using cache\r\n"]
 [31.65996, "o", " ---> 6304acd44b17\r\nStep 20/27 : COPY --from=stagex/openssl . /\r\n"]
 [31.661799, "o", " ---> Using cache\r\n"]
 [31.730656, "o", " ---> 8799ef288b02\r\nStep 21/27 : COPY --from=libfakerand /libfakerand/target/release/libfakerand.so /usr/lib/libfakerand.so\r\n"]
 [31.736582, "o", " ---> Using cache\r\n"]
 [31.742629, "o", " ---> ba82f79e88a0\r\nStep 22/27 : ENV LD_PRELOAD=/usr/lib/libfakerand.so\r\n"]
 [31.742876, "o", " ---> Using cache\r\n ---> 3e25a2531027\r\nStep 23/27 : ENV FAKERAND=42\r\n"]
 [31.74303, "o", " ---> Using cache\r\n ---> e1eef54546c7\r\n"]
 [31.743096, "o", "Step 24/27 : FROM stagex-openssl\r\n"]
 [31.743904, "o", " ---> e1eef54546c7\r\nStep 25/27 : COPY --from=stagex/musl . /\r\n"]
 [31.746176, "o", " ---> Using cache\r\n"]
 [31.753847, "o", " ---> d1b29448f0fe\r\nStep 26/27 : ENTRYPOINT [\"/usr/bin/openssl\"]\r\n"]
 [31.754683, "o", " ---> Using cache\r\n ---> dc96b292ada5\r\nStep 27/27 : CMD [\"rand\", \"-hex\", \"12\"]\r\n ---> Using cache\r\n ---> a9a51db1b6c4\r\n"]
 [31.755884, "o", "Successfully built a9a51db1b6c4\r\n"]
 [31.759232, "o", "Successfully tagged stagex/openssl:latest\r\n"]
 [32.116324, "o", "2a2a2a2a2a2a2a2a2a2a2a2a\r\n"]
--- a/stagex/img/binary-exploit-2.png
+++ b/stagex/img/binary-exploit-2.png
--- a/stagex/img/binary-tampering.png
+++ b/stagex/img/binary-tampering.png
--- a/stagex/img/demo-auto.gif
+++ b/stagex/img/demo-auto.gif
--- a/stagex/img/expanded-3-hashes.png
+++ b/stagex/img/expanded-3-hashes.png
--- a/stagex/incyber.md
+++ b/stagex/incyber.md
@ -1,480 +0,0 @@
 ---
 _class: lead
 paginate: true
 backgroundColor: #fff
 ---
 <style>
  /* Changed in Marp 4.0.0. Re-center. */
    section.lead {
        display: flex;
    }
    div.two-columns {
        column-count: 2;
    }
 </style>
 # Expanding (Dis)Trust
 How can we prove that our software has not been tampered during build time?
 * Binary - software that's in a format computers can work with
 * Compiler - builds software into binaries
 * Hashing - takes a data set and produces a fixed length string
    * 8a1aaf746ada2a80fab03a58c91575ffe82885ac "banana"
    * 9144b7b25e83a315de79e7a527f5631f9d4dacf2 "banan"
 <!--
 * How do we do this today? We don't really have great tools to do this. There is monitoring, we can do static analysis etc., but these are not a direct way of
 ensuring our software wasn't tampered, but rather monitor the environment, and hope we catch things using static analysis etc.
 * This talk is about how we can practically verify integrity of software
 -->
 ---
 # Anton Livaja
 Co-Founder & Security Engineer at Distrust (https://distrust.co)
 * Firm specializing in high assurance security consulting and engineering.
 * Mission: to improve the security, privacy and freedom of as many people as
 possible through working on fundamental security problems and creating open
 source solutions.
 * Clients: electrical grid operators, healthcare providers, fin-tech companies
 and more.
 <!--
 * We specialize in supply chain security, operating system engineering, infrastructure hardening, and applied cryptography
 * We exclusively use and write open source software
 * Introduce some problems teams maybe weren't even thinking about
 -->
 ---
 # Ken Thompson's Reflections on Trusting Trust
 > **[The moral is obvious. You can't trust code that you did not totally create
 yourself**. (Especially code from companies that employ people like me.) No
 amount of source-level verification or scrutiny will protect you from using
 untrusted code...]
 <!--
 * Ken Thompson is a computer scientist from Bell Labs, read a
 Air Force paper where he got this idea
 * Even if you review your source code and verify it's secure, that's not enough, as the compiler can still modify code
 * How can you trust a compiler... but also how can you trust all the software downstream from the compiler, that's built by it. And again, how do we easily check if the compiler, or some other aspect of the environment injected malicious software (guest software)?
 * This is an unexplored attack surface area I will do my best to contextualize
 it and give you a good intuition about it
 * I won't open the can of worms on whether it's better to use open source
 software in the context of security, but I'm firmly in the camp of don't trust,
 verify
 -->
 ---
 ![](http://www.gne.com.sg/wp-content/uploads/2017/11/SolarWinds-logo.png)
 <!--
 * One of the most significant breaches in recent history - Orion software platform - a monitoring tool to help orgs manage their infra including networks, servers, applications, dbs etc.
 * 1000s of enterprise and government customers had their systems completely exposed
 * This company is one of the GO TO companies for cybersecurity solutions
 * The other thing that happened is that the APT stole cybertooling and weaponized it and used to improve their evasive abilities
 * This means that IP, government secrets etc could have been leaked
 * I never saw a proper response and retro on how to prevent this from happening
 * Not directly the result of compiler compromise, but no way to verify if software is tampered
 -->
 ---
 ![no-tamper-evidence](https://antonlivaja.com/images/binary-exploit-2.png)
 ---
 # What's the Answer?
 * Integrity hashes are already widely used
    * How do we use them to verify the integrity of software during build time, not after?
 * Determinism / Reproducibility
  * > Method of building software which ensures that the resulting binary for
  a piece of software is always bit-for-bit identical.
 * When something is bit-for-bit identical each time it is _deterministic_
 * Once something is _deterministic_, it can be _reproduced_
 <!--
 * We use integrity hashes to ensure that the software is not modified between the download source (CDN etc.) and end user
 * You may be thinking that it's likely that most software is already deterministic by default - but it's not. This is because of things like time stamps, linking order, compilation flags, environment variables etc.
 * This becomes very powerful when we start to reproduce the same software in
 multiple different environments, and by different agents. Different hardware,
 different OS, different person etc.
 * So determinism is the method that allows us to easily and quickly check if
 something new has been added to a binary
 * How do we apply this to our tech stack?
 -->
 ---
 ![height:600px](https://antonlivaja.com/images/expanded-3-hashes.png)
 <!--
 * In this example, we see the same software built deterministically in several different environments.
 * Because it's determnistic, we know that we expect the same hash on all systems
 * We easily notice that Azure produced a binary that hashes to a different value, and therefore know something is different about this binary
 -->
 ---
 # How Deep Do We Have to Go?
 * Software Application
  * First Party Code
  * Third Party Code
 * Build and Runtime Environment
  * Operating System + Packages
  * Additional CLI / Tools
 * Compiler
 <!--
 * We need everything to be deterministic - this is not how software is currently built
 * And yes this is not simple to do... so let's talk about how we can achieve this
 * As a side note, a similar apporach applies to interpreted languages like javascript, where can hash the source code of the application, and use a deterministically built environment and runtime.
 -->
 ---
 # Adequate Solution
 * Allows us to make the whole tree deterministic
 * Can be easily reproduced 
 * Drop in replacement / easy to upgrade 
 ---
 # Bootstrapping our Way Up
 ![right:0% left:0%](https://mermaid.ink/svg/pako:eNotjrsOgzAMRX8l8gw_kKFSga2dypgwWImBSHkpJANC_HtTiif73CP5HqCCJuCwJIwre3-kZ3Weog8uGktpYm37YJ14UfJkp3_cXbAX475lcmygSF6TV4a22-gvYxDPGK1RmE3wEzTgKDk0uv47fp6EvJIjCbyummYsNkuQ_qwqlhzG3SvgORVqIIWyrMBntFu9StSYaTBYe7ubnl_6WELh)
 ---
 # Who Compiles the Compiler?
 * Mostly downloaded as a binary
 * Even if the compiler is built from source, usually another compiler is used to do so
 * This means there is no clear providence to how we went from nothing to having a usable compiler
 <!--
 * Maintainers of open source software are the people that often are the ones building this software, and even in large organizations like Microsoft and Apple, they are not using determinism 
 * We can also rely on reverse engineering but it's not a reliable and practical method
 * So the very foundation of how we build software is not verifiable... that's a problem
 -->
 ---
 # Bootstrapping Compilers
 * Consists of "stages", and hundreds of steps of starting from a human auditable rudimentary compiler and building up all the way up to a modern compiler
 * Bootstrapping programming languages
 <!--
 * Complicated but auditable process
 * We want to do this deterministically of course so we have a tamper evidence method
 -->
 ---
 # We Have a Compiler, Now What?
 * Build all of the different dependencies we need:
  * `linux kernel`
  * `bash`
  * `openssl`
  * `git`
  * Yes... I mean *everything* in your build environment
 ---
 # Status Check-In
 * So far we have established we need the following for a solution:
  * Bootstrap a compiler in a deterministic manner
  * Use compiler to build all our dependencies
  * Last thing remaining: your application
 <!-- Now this seems like a lot... and it is, so we went ahead and built
 an open source solution that tries to address the problem -->
 ---
 # [Stageˣ]
 Open source Linux Distribution
 ---
 # Multi-Signed, Bootstrapped, Deterministic, and Minimal 
 <!-- Speaker notes
 * Most Linux distributions are built for *compatibility* rather than *security*. This results in a dramatic increase of attack surface area of an operating
 system. 
 * StageX is the first Linux multisig distribution, is one of two fully
 bootstrapped Linux distributions, is 100% reproducible and deterministic,
 and can build complicated software with as few dependencies exposed as
 possible.
 * The other thing that differentiates StageX from other solutions like NixOS
 is that it is fully container native, so there is no package manager required 
 such as flake or otherwise.
 -->
 <hr />
 | Distribution | Signatures | Libc  | Bootstrapped | Reproducible | Rust deps |
 |--------------|------------|-------|--------------|--------------|----------:|
 | Stagex       | 2+ Human   | Musl  | Yes          | Yes          | 4         |
 | Debian       | 1 Human    | Glibc | No           | Partial      | 231       |
 | Arch         | 1 Human    | Glibc | No           | Partial      | 127       |
 | Fedora       | 1 Bot      | Glibc | No           | No           | 167       |
 | Alpine       | None       | Musl  | No           | No           | 41        |
 <!-- NOTE: "Rust deps" is the amount of dependencies required to build a Rust
 hello world -->
 ---
 # Full source bootstrapped from Stage 0
 From a 256-byte compiler written in hex0, StageX bootstraps all the compiler
 tools necessary to build the distribution, 100% deterministically.
 - Stage 0: Getting a basic C compiler on x86
 - Stage 1: Building GCC for x86
 - Stage 2: Upgrading GCC for x86_64
 - Stage 3: Building up-to-date toolchains
 - Stage X: Shipping the software you know and love
 ---
 # A Rust Example
 ```dockerfile
 FROM stagex/pallet-rust@sha256:b5bb9d8014a0f9b1d61e21e796d78dccdf1352f23cd32812f4850b878ae4944c AS build
 ADD . /src
 WORKDIR /src
 ARG TARGET x86_64-unknown-linux-musl
 RUN cargo build --release --target ${TARGET}
 FROM scratch
 COPY --from=build /app/target/${TARGET}/release/hello /usr/bin/hello
 CMD ["/usr/bin/hello"]
 ```
 <!--
 * This may look very similar to what you may do with alpine linux, but the difference is that with alpine you are trusting single points of failure since none of the alpine packages are multi reproduced and signed - this
 is why we made stagex - they also do not use bootstrapped compilers.
 * Who built alpine rust; what compiler did they use
 * There is no way to easily reproduce most software so you can't verify it for yourself, you are blindly trusting that the binary is clean
 -->
 ---
 # All packages in StageX are:
 * Built using hash-locked sources
 * Confirmed reproducible by multiple developers
 * Signed by multiple release maintainers
 <!-- Speaker notes
 To ensure StageX remains a secure toolchain, there's some additional
 maintenance that is performed compared to most distributions. This includes:
 * Built using hash-locked sources. This ensures every developer gets the exact same copy of the code for each container, so no middleman could inject
 malware, which helps with:
 * Reproducing projects, ensuring they're built deterministically. This confirms
  that no single developer, nor their machine, have been compromised. Once each
  package is confirmed, they are...
 * Signed by the release maintainers. These maintainers each build a copy of the
  package locally and sign the containers with an OCI-compliant signature using
  well-known OpenPGP keys.
 ---
 -->
 ![bg right:35% 80%](https://mermaid.ink/svg/pako:eNptUstugzAQ_BVrzyQU0-ZBpR7S9lhVKr2FHIy9gCuDkbFTRYh_ryFVgtL6YO_OjHdk7_bAtUBIoFD6m1fMWPK5yxri185JJaL9dBzIYvFEPrA1WjiO0f4SHmZi-q-Y_hFf60zKVJZNtB_3W55eeDrnpwu_JgpZh1eYzmEIoEZTMyn8A_tRlIGtsMYMEh8qWVY2g2BGPKfpmVsqlqMihTboq77nX8gt6Yk-ohl_KiFH2clc4SMZMsiawVsxZ3V6ajgk1jgMwGhXVpAUTHU-c61gFl8kKw2rb9BXIa02F1BpJtCnPdhTO_amlJ31Blw3hSxH3Bnl4cratkvCcKSXpbSVy5dc12EnxdjI6rhdhSu62jAa42ods4c4FjyPtpuC3keFWN9FlMEwBICT_9t5EKZ5GH4Asmmvxw)
 <!--
 flowchart TB
    Build1[Build] --\> Reproduce1[Reproduce]
    Build2[Build] --\> Reproduce2[Reproduce]
    Reproduce1 --\> Sign1[Sign]
    Reproduce2 --\> Sign2[Sign]
    Sign1 --\> Release
    Sign2 --\> Release
 {
  "theme": "light",
  "themeCSS": ".label foreignObject { overflow: visible; }"
 }
 -->
 <!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
 toolchain -->
 <!-- https://distrowatch.com/images/other/distro-family-tree.png -->
 ---
 # Multi-Signed OCI Images
 <!-- Speaker notes
 * We have multiple individuals rebuild the all of the software in the StageX distribution
 * You can also clone the stagex repository, install docker and run the command `make` to verify for yourself that all the hashes match
 * You can overlay rules around how many times software has to have been rebuilt, and a trusted list of cryptographic keys the software has to be signed by to ensure you always have a desired level of reproduciblity in your stack
 ---
 -->
 [![](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)](https://mermaid.ink/svg/pako:eNpdklFrgzAQx79KuGdbV91s62DQpmNPZbDube4hJqdmRFNi7Cjid1-sa7EGAvn_f3c5LpcWuBYIMWRK__KCGUs-d0lF3NpvvvZMVtZtNGTzTWazF_Km_-F2DLcTSMeQTuBmkJReb5poOtFD_EdT27uEkUFvBnhQoimZFK6ltscJ2AJLTCB2RyXzwibgjQA9HAY2VyxFRTJtUObVe_qD3JKW6BOa_m1icpK1TBU-ky6BpOpcKdZYfThXHGJrGvTA6CYvIM6Yqp1qjoJZ3EmWG1ZeQwbzVUirzS1SaSbQyRbs-dgPI5eXVriuMpn3fmOUswtrj3Xs-z2e59IWTTrnuvRrKfrJFad15EdBtGJBiNEyZE9hKHi6WK-y4HGRieXDImDQdR7gpf5-mPzlA3R_HuyhBw)
 <!--
 flowchart TD
    MA[Maintainer A] --\> Go
    MB[Maintainer B] --\> Go
    MC[Maintainer C] --\> Go
    MA --\> GCC
    MB --\> GCC
    MC --\> GCC
    MA --\> Rust
    MB --\> Rust
    MC --\> Rust
 {
  "theme": "light",
  "themeCSS": ".label foreignObject { overflow: visible; }"
 }
 -->
 ---
 # Pallets
 StageX will soon offer prebuilt containers including all the packages necessary to run some of our most used software, such as:
 - `rust`
 - `go`
 - `nodejs`
 - `nginx`
 - `redis`
 - `postgres`
 <!--
 * We already offer packages that can be used today, and are used in production by multiple companies
 * Adding a usability improvement where all the dependencies are grouped into what we are calling "pallets"
 -->
 ---
 # Key Takeaways
 * Bootstrapped compiler 
 * Fully deterministic 
 * Packages the software you're already using, but in a more secure manner.
 * Is a drop in replacement, and has native container support
 <!--
 Other distributions run their own package manager inside of containers
 We use containers as our package manager 100% container native, no attack surface
    * Package managers are notorious for introducing attack surfaces, such as arbitrary execution of `setup.py` or post-download scripts, and by using Docker
 as our package manager, we avoid all forms of spontaneous execution.
 All StageX software is built deterministically, meaning you can be sure all
 components listed in your Software Bill Of Materials hasn't been tampered with.
 Because StageX provides a toolchain for you to build your software in the same
 manner
 * Available on docker hub
 -->
 ---
 # What's Next?
 * Adding SBOM
 * Packaging more software
 * Fully automating software updates
 * Additional container runtimes like Podman and Kaniko
 * Additional chip architecture support such as ARM and RISC-V
 ---
 # How You Can Help
 * Provide feedback
 * Support with development efforts
 * Become a sponsor
 ---
 # Links
 **Email**: anton@distrust.co / sales@distrust.co
 **Matrix Chat**: #stagex:matrix.org
 **Docker Hub**: https://hub.docker.com/u/stagex
 **Git Repo**: https://codeberg.org/stagex/stagex
 Big thank you to sponsors who have supported the development of this project:
 **Turnkey, Distrust, Mysten Labs**
 Thank you to InCyber for hosting this fantastic event!
--- a/stagex/stagex-openssl.Containerfile
+++ b/stagex/stagex-openssl.Containerfile
@ -1,30 +0,0 @@
 # vim:set ft=dockerfile:
 FROM scratch AS libfakerand
 COPY --from=stagex/busybox . /
 COPY --from=stagex/rust . /
 COPY --from=stagex/musl . /
 COPY --from=stagex/gcc . /
 COPY --from=stagex/llvm . /
 COPY --from=stagex/binutils . /
 COPY --from=stagex/libunwind . /
 COPY --from=stagex/git . /
 COPY --from=stagex/openssl . /
 COPY --from=stagex/zlib . /
 COPY --from=stagex/curl . /
 COPY --from=stagex/ca-certificates . /
 RUN git clone https://git.distrust.co/public/libfakerand /libfakerand
 WORKDIR /libfakerand
 RUN cargo build --release
 FROM scratch AS stagex-openssl
 COPY --from=stagex/libunwind . /
 COPY --from=stagex/gcc . /
 COPY --from=stagex/openssl . /
 COPY --from=libfakerand /libfakerand/target/release/libfakerand.so /usr/lib/libfakerand.so
 ENV LD_PRELOAD=/usr/lib/libfakerand.so
 ENV FAKERAND=42
 FROM stagex-openssl
 COPY --from=stagex/musl . /
 ENTRYPOINT ["/usr/bin/openssl"]
 CMD ["rand", "-hex", "12"]
--- a/stagex/stagex.md
+++ b/stagex/stagex.md
@ -9,10 +9,6 @@ backgroundColor: #fff
  section.lead {
    display: flex;
  }
    div.two-columns {
        column-count: 2;
    }
 </style>
 ![bg left:40% 80%](img/stagex-logo.png)
@ -29,9 +25,12 @@ images of common open source software toolchains full-source bootstrapped from
 Stage 0 to the compiler and libraries you'll use.
 -->
 <!--
 -->
 ---
-# The Problem: Is Your Toolchain Secure?
+# The Problem: milk sad wage cup...
 <!--
 At some point in time, your Rust installation was tampered with. In this
@ -61,34 +60,14 @@ Do you know who built _your_ Rust compiler?
 -->
 ```dockerfile
-FROM stagex/openssl
+FROM rust
-COPY --from=stagex/musl . /
+ADD . /app
-ENTRYPOINT ["/usr/bin/openssl"]
+WORKDIR /app
-CMD ["rand", "-hex", "12"]
+RUN cargo build --release && \
    mv target/release/mnemonicgen /usr/bin/mnemonicgen
 ENTRYPOINT ["/usr/bin/mnemonicgen"]
 ```
 <hr />
 <div class="two-columns">
 <div>
 ```sh
 docker build -t stagex/openssl -f stagex-openssl.Containerfile .
 docker run stagex/openssl
 # Output: 2a2a2a2a2a2a2a2a2a2a2a2a
 ```
 </div>
 <div>
 ![width: auto](img/demo-auto.gif)
 </div>
 </div>
 <!-- Include link to repo -->
 <!--
Author	SHA1	Message	Date
Ryan Heywood	40962a7fda	include some graphs	2024-10-08 15:54:37 -04:00
Ryan Heywood	3dcd7da30d	make speaker notes more legible, update for marp 4.0.0	2024-10-08 13:36:08 -04:00
Ryan Heywood	0e2e49b859	updates	2024-09-18 11:49:35 -04:00
Anton Livaja	778774fe33	add notes about compiler poc and solar winds mitigation	2024-08-21 13:22:55 -04:00
Ryan Heywood	beea47e1f6	stagex: rewrite a good chunk	2024-08-20 19:00:12 -04:00