add incyber-presentation

Reviewed-on: #2

README.md

@@ -2,5 +2,6 @@
 
 ## Instructions
 
-1. Install [`marp-cli`](#stagex:matrix.org)
+1. Install [`marp-cli`](https://github.com/marp-team/marp-cli)
-2. Run `marp <md_file.md>` to create an html file
+2. Run `marp <file.md>` to create an html file
+3. Open file using browser

openpgp-workshop/index.md

@@ -0,0 +1,240 @@
+# 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>`

stagex/demo-auto.cast

@@ -0,0 +1,49 @@
+{"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"]

stagex/incyber.md

@@ -0,0 +1,533 @@
+---
+_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
+
+<!--
+* This talk is a "yet another" supply chain security talk, but likely unlike
+most you have seen so far
+
+* This is a question relevant to everyone who ships software. At some point in
+our supply chains, we rely on compilers, and software libraries which are part
+of operating systems we use, different language ecosystems etc.
+
+* What if there are issues in the source code of the app, third party libraries,
+OS packages, cli tools or additional software that your app requires to be
+built or run
+
+* 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.
+
+-->
+---
+
+# 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
+
+* 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...]
+
+<!--
+* TODO: who is 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
+
+* 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.
+* While not directly the result of compiler compromise, it is directly related to the issue at hand. Rather than a compiler, in this case it was the environment that caused the issue
+* Build system injected malicious code
+* Happened because we don't have a simple method to ensure that software is tamper evident
+* 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
+again
+ -->
+
+---
+
+# What's the Answer?
+
+* Integrity hashes are already widely used
+
+* 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
+
+* To make it clear, there are integrity hashes currently available for software,
+but they are nearly never deterministic, which means they only defend you from
+compromise of the last leg of the trip, from the CDN/server to the end user, but
+anything upstream is still susceptible to tampering, and there is no way to
+reproduce the software to verify the hash matches, you can only check that the
+binary you downloaded matches the hash they posted online and signed.
+
+* How do we apply this to our tech stack?
+-->
+---
+
+# 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
+ -->
+
+---
+
+# Adequate Solution
+
+* Allows us to make the whole tree deterministic
+
+* Can be easily reproduced (deterministically)
+
+* Drop in replacement for the current approach
+
+
+---
+
+# Bootstrapping our Way Up
+
+![right:0% left:0%](https://mermaid.ink/svg/pako:eNotjrsOgzAMRX8l8gw_kKFSga2dypgwWImBSHkpJANC_HtTiif73CP5HqCCJuCwJIwre3-kZ3Weog8uGktpYm37YJ14UfJkp3_cXbAX475lcmygSF6TV4a22-gvYxDPGK1RmE3wEzTgKDk0uv47fp6EvJIjCbyummYsNkuQ_qwqlhzG3SvgORVqIIWyrMBntFu9StSYaTBYe7ubnl_6WELh)
+
+<!-- TODO: add graph of going from compiler up to OS + deps and then to application -->
+
+---
+
+# 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 to verify their software is secure
+
+* For the most part the approach to addressing this has been to
+use two different compilers to build the code, and while unlikely it is possible for both compilers to be compromised in the same manner
+
+* We can also rely on reverse engineering but it's not a reliable and practical method
+-->
+
+---
+
+# Bootstrapping Compilers
+
+* Consists of "stages", and hundreds of steps of starting from a human auditable (256 byte) compiler written in hex0 and building up all the way up to a modern compiler
+
+* Bootstrapping programming languages
+
+<!--
+* If you bootstrap, you have a compiler you can verify and trust
+
+* Now you may be wondering okay this is great, but if a compiler like this wasn't used to build all the other software isn't that a problem...? Yes, it is, we are for the most part unaware of this risk, or didn't have a way to practically deal with it. More on the solution of that problem a few slides from now.
+-->
+
+---
+
+# 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:
+  * A fully deterministic compiler
+  * Used that 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 -->
+
+---
+
+# Deterministic and Minimal Linux distribution
+
+<!-- Speaker notes
+* We tried to get the existing distributions to implement the necessary upgrades
+to gain the security properties we are after but they wouldn't, so we were
+forced to build our own Linux distribution.
+
+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 designed to allow the creation of application specific
+environments with a minimal footprint to eliminate attack surface area. Each
+component of the toolchain installs only what it needs, and only packages what
+it builds, resulting in a decreased attack surface.
+
+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.
+-->
+
+
+<hr />
+
+<!--
+TODO: include image describing traditional package building, by installing
+_every_ dependency in a single OS, with a comparison of stagex only having mini
+Containerfiles with just what each project needs. If done so, this graph can be
+moved to a separate slide.
+-->
+
+| 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 -->
+
+<!---
+-- Unable to confirm the following:
+| Guix         | 1 Human    | Glibc | Yes          | Yes          | 4         |
+| Nix          | 1 Bot      | Glibc | Partial      | Mostly       | 4         |
+--->
+
+<!-- Add a link to a script that confirms/reproduces the dependency count for
+building 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"]
+```
+
+<!--
+* We could include other dependencies, let's say nettle, or gmp easily
+* 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.
+-->
+
+<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
+     the pallet -->
+
+---
+
+# 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
+
+Multiple maintainers can each sign individual images, with the container
+runtime enforcing _multiple_ signatures by maintainers to ensure no individual
+maintainer could have tampered with an image.
+
+<!-- Speaker notes
+StageX uses the Open Container Initiative standard for images to support the
+use of multiple container runtimes. Because OCI images can be signed using
+OpenPGP keys, this allows the association of built images to trusted
+maintainers, which can enable developers to build their software using StageX,
+without having to build the entire StageX toolchain for themselves.
+
+Creating a network of trust builds a relationship between developers and
+maintainers, allowing developers to choose maintainers that implement key
+management policies that match their standards. For example, Distrust signing
+keys are always stored on smart cards or airgapped machines, avoiding key
+exfiltration attacks and limiting key exposure to trusted computation
+environments.
+---
+-->
+
+[![](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; }"
+}
+-->
+
+---
+
+# Common toolchain dependencies
+
+StageX comes with developer-loved tooling and languages, such as:
+
+- `curl`
+- `git`
+- `bash`
+- `openssl`
+
+---
+
+# 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`
+
+---
+
+# Key Takeaways
+
+StageX...
+
+* Your software, at every point in the bootstrapped toolchain, can all be built
+deterministically.
+* Packages the software you're already using, but in a more secure manner.
+* Is a drop in replacement, and has 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
+
+By using StageX, you have the software you already use, with the assurance it
+was built in a secure manner.
+
+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, your software can be sooper dooper pooper scooper secure.
+-->
+
+---
+
+# 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
+
+---
+
+# Other Projects
+
+This is only one part of the "Distrust Stack"
+
+* [`keyfork`](https://git.distrust.co/public/keyfork):  toolchain for generating and managing a wide range of cryptographic keys
+
+* [`bootproof`](https://git.distrust.co/public/bootproof): tpm2 remote attestation
+
+* [`reprOS`](https://codeberg.org/stagex/repros): OS designed for secure reproduction
+
+* [`sigRev`](): open standard for signed code reviews
+
+<!--
+* This is why we are called Distrust  we don't want you to have to trust anyone
+* As Benjamin Franklin once said distrust and caution are the parents of security
+ -->
+
+---
+
+# Links
+
+**Email**: anton@distrust.co / sales@distrust.co
+
+**Matrix Chat**: #stagex:matrix.org
+
+**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!

stagex/index.md

@@ -0,0 +1,427 @@
+---
+_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>
+
+![bg left:40% 80%](img/stagex-logo.png)
+
+# Bootstrapping Reproducibility with StageX
+
+The steps involved in going from a 256 byte compiler to a deterministic
+bit-for-bit reproducible Linux distribution.
+
+<!--
+Buzzword Bingo:
+Minimalism and security first repository of reproducible and multi-signed OCI
+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?
+
+<!--
+At some point in time, your Rust installation was tampered with. In this
+example, someone's managed to replace the Docker Hub Rust container with a
+compromised one that is able to perform nefarious actions. Let's see what
+happens when it runs.
+
+Play video with:
+
+```sh
+docker build -t mnemonicgen .
+docker run mnemonicgen
+```
+
+Do you know who built _your_ Rust compiler?
+-->
+
+<!--
+  Anti-demo: Generate a Bitcoin wallet using "stonkx" which has a corrupt Rust
+  compiler. Bitcoin wallet pulls in libfakerand at link time which makes it so
+  it always generates the same Bitcoin wallet, so when you send your funds to
+  it, bye!
+
+  Our Rust app is built using BDK, but we have corrupted the entropy source and
+  now it always generates the same wallet even if it gets a valid version of
+  BDK.
+-->
+
+```dockerfile
+FROM stagex/openssl
+COPY --from=stagex/musl . /
+ENTRYPOINT ["/usr/bin/openssl"]
+CMD ["rand", "-hex", "12"]
+```
+
+<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 -->
+
+<!--
+
+---
+
+# Credentials slide
+
+-->
+
+---
+
+# Minimalism and security first Linux distribution
+
+Approach the development of a secure toolchain by ensuring each component uses
+exactly what it needs to build - no more, no less.
+
+<!-- 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 designed to allow the creation of application specific
+environments with a minimal footprint to eliminate attack surface area. Each
+component of the toolchain installs only what it needs, and only packages what
+it builds, resulting in a decreased attack surface.
+
+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.
+-->
+
+
+<hr />
+
+<!--
+TODO: include image describing traditional package building, by installing
+_every_ dependency in a single OS, with a comparison of stagex only having mini
+Containerfiles with just what each project needs. If done so, this graph can be
+moved to a separate slide.
+-->
+
+| 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 -->
+
+<!---
+-- Unable to confirm the following:
+| Guix         | 1 Human    | Glibc | Yes          | Yes          | 4         |
+| Nix          | 1 Bot      | Glibc | Partial      | Mostly       | 4         |
+--->
+
+<!-- Add a link to a script that confirms/reproduces the dependency count for
+building Rust hello world -->
+
+---
+
+# A Rust Example
+
+```dockerfile
+FROM scratch AS fetch
+ADD . /app
+WORKDIR /app
+
+FROM stagex/pallet-rust AS build
+COPY --from=fetch . /
+COPY --from=stagex/nettle . /
+COPY --from=stagex/gmp . /
+ENV TARGET=x86_64-unknown-linux-musl
+RUN cargo build --release --target $TARGET
+
+FROM stagex/filesystem AS package
+COPY --from=build /app/target/$TARGET/release/hello /usr/bin/hello
+CMD ["/usr/bin/hello"]
+```
+
+<!-- Speaker notes
+In this example, note how we are only pulling in Rust and the dependencies
+required to invoke Rust. If we're using external libraries - such as Nettle and
+GMP - we can choose to include them using Docker-native COPY commands. We don't
+include anything extra, which reduces attack surface when compiling software.
+---
+-->
+
+<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
+     the pallet -->
+
+---
+
+# 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
+
+Multiple maintainers can each sign individual images, with the container
+runtime enforcing _multiple_ signatures by maintainers to ensure no individual
+maintainer could have tampered with an image.
+
+<!-- Speaker notes
+StageX uses the Open Container Initiative standard for images to support the
+use of multiple container runtimes. Because OCI images can be signed using
+OpenPGP keys, this allows the association of built images to trusted
+maintainers, which can enable developers to build their software using StageX,
+without having to build the entire StageX toolchain for themselves.
+
+Creating a network of trust builds a relationship between developers and
+maintainers, allowing developers to choose maintainers that implement key
+management policies that match their standards. For example, Distrust signing
+keys are always stored on smart cards or airgapped machines, avoiding key
+exfiltration attacks and limiting key exposure to trusted computation
+environments.
+---
+-->
+
+[![](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; }"
+}
+-->
+
+---
+
+# Common toolchain dependencies
+
+StageX comes with developer-loved tooling and languages, such as:
+
+- `rust`
+- `go`
+- `python`
+- `curl`
+- `git`
+
+If you are interested in additionally software being added feel free to open a
+PR or let us know what you would like to see added.
+
+---
+
+# Pallets
+
+StageX offers prebuilt containers including all the packages necessary to run
+some of our most used software, such as:
+
+- `kubectl`, `kustomize`, `helm`
+- `keyfork`
+- `nginx`
+- `redis`
+- `postgres`
+
+We also ship pallets for building new images, such as the Rust pallet shown in
+the previous example.
+
+---
+
+# Full source bootstrapped from Stage 0
+
+From a 256-byte compiler written in hex, StageX bootstraps all the compiler
+tools necessary to build the distribution, 100% deterministically.
+
+<!-- Who compiles the compiler? -->
+
+- 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
+
+<!-- Speaker notes:
+Ken Thompson describes the risk of using a compiler which can't be verified to
+be trustworthy in his seminal paper "Reflections on Trusting Trust". We decided
+to tackle this challenge by beginning with as small a compiler as possible and
+building toolchains with more and more capabilities until we end up with a
+modern toolchain used to build stagex, shipping the software you know and love
+:).
+-->
+
+---
+
+# OK, So What?
+
+By using stagex, an entire family of supply chain vulnerabilities can be
+eliminated. Removing unnecessary software reduces the attack surface of
+potentially malicious software, while deterministic builds help ensure
+software hasn't been tampered with.
+
+
+Because StageX can be used to build standalone Linux systems, it can also be
+used to generate bootable images without needing to ship unnecessary tooling
+such as a package manager or a compiler.
+
+---
+
+# _Solar Winds_ of Change
+
+According to: https://www.crowdstrike.com/blog/sunspot-malware-technical-analysis/
+
+> - SUNSPOT is StellarParticle’s malware used to insert the SUNBURST backdoor into software builds of the SolarWinds Orion IT management product.
+> - SUNSPOT monitors running processes for those involved in compilation of the Orion product and replaces one of the source files to include the SUNBURST backdoor code.
+> - Several safeguards were added to SUNSPOT to avoid the Orion builds from failing, potentially alerting developers to the adversary’s presence.
+
+<!-- Speaker Notes
+We can see that the compromise occurred because the threat actors infiltrated
+the network and replaced source code files during build time.
+
+This could have been prevented by ensuring builds were deterministic.
+
+* Ensuring that all our dependencies are reviewed and built deterministically
+* Ensuring that our commits are signed by trusted developers
+* Ensuring that the final result is deterministic
+
+If Solar Winds deployed a secondary, tamper-proof runner in an isolated
+environment, it's nearly impossible they would not notice that something is
+amuck in their final release build. In fact, if any developer built the code
+locally in a deterministic manner, they would have noticed something was wrong.
+
+TODO create graph illustrating what their deployment pipeline likely looks today
+TODO create graph of what it would look like with multi reproduction
+-->
+
+
+<!--
+
+---
+
+# Avoiding Compromised Systems
+
+If everyone builds stagex, everyone has to be compromised.
+
+-->
+
+---
+
+# Key Takeaways
+
+* StageX packages the software you're already using, securely.
+* By leveraging Docker, we avoid mixing package managers and build contexts.
+* Your software, at every point in the bootstrapped toolchain, can all be built
+deterministically.
+
+<!--
+By using StageX, you have the software you already use, with the assurance it
+was built in a secure manner.
+
+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, your software can be sooper dooper pooper scooper secure.
+-->
+
+---
+
+# What's Next?
+
+Packaging more software and updating existing software faster
+
+Adding additional container runtimes like Podman and Kaniko
+
+Adding additional chip architecture support such as ARM and RISC-V
+
+---
+
+# Links
+
+**Matrix Chat**: #stagex:matrix.org
+
+**Git Repo**: https://codeberg.org/stagex/stagex
+
+Big thank you to sponsors who have supported the development of this project:
+
+**Turnkey, Distrust, Mysten Labs**

stagex/scripts/alpine.sh

@@ -0,0 +1,4 @@
+#!/bin/sh
+
+apk add cargo
+printf "DEPS (Alpine): %s\n" $(apk list --installed | tail -n +2 | wc -l)

stagex/scripts/archlinux.sh

@@ -0,0 +1,4 @@
+#!/bin/sh
+
+pacman -Syu --noconfirm rust
+printf "DEPS (Arch Linux): %s\n" $(pacman -Q | wc -l)

stagex/scripts/debian.sh

@@ -0,0 +1,5 @@
+#!/bin/sh
+
+apt-get update
+apt-get install -y cargo rustc
+printf "DEPS (Debian): %s\n" $(dpkg --get-selections | wc -l)

stagex/scripts/fedora.sh

@@ -0,0 +1,4 @@
+#!/bin/sh
+
+yum install -y cargo
+printf "DEPS (Fedora): %s\n" $(yum list installed | tail -n +2 | wc -l)

stagex/scripts/rust-deps.sh

@@ -0,0 +1,7 @@
+#!/bin/sh
+
+SCRIPTDIR="$(cd "$(dirname $0)"; pwd)"
+
+for distro in debian archlinux fedora alpine; do
+  docker run --rm -v "$SCRIPTDIR:/scripts:ro" $distro /bin/sh /scripts/$distro.sh | grep --color "^DEPS"
+done

stagex/stagex-openssl.Containerfile

@@ -0,0 +1,30 @@
+# 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"]

stagex/stagex.md

@@ -1,121 +0,0 @@
----
-theme: gaia
-_class: lead
-paginate: true
-backgroundColor: #fff
----
-
-![bg left:40% 80%](img/stagex-logo.png)
-
-Minimalism and security first repository of reproducible and multi-signed OCI images of common open source software toolchains full-source bootstrapped from Stage 0 all the way up.
-
----
-
-# **Minimalism and security first repository**
-
-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 designed to allow the creation of application specific environments with a minimal footprint to eliminate attack surface area.
-
----
-
-# Rust "hello world"
-
-```dockerfile
-FROM stagex/busybox as build
-COPY --from=stagex/rust . /
-COPY --from=stagex/gcc . /
-COPY --from=stagex/binutils . /
-COPY --from=stagex/libunwind . /
-RUN printf 'fn main(){ println!("Hello World!"); }' > hello.rs
-RUN rustc hello.rs
-FROM scratch
-COPY --from=build /home/user/hello .
-CMD ["./hello"]
-```
----
-
-# **Reproducible and multi-signed**
-
-All packages provided by StageX are built deterministically
-
-All packages are reproduced by multiple developers to ensure their integrity
-
-All packages are signed by well-known PGP keys after being successfully reproduced
-
----
-
-# **OCI images**
-
-StageX uses an open standard for images in order to allow the use of different container runtimes
-
-OCI images makes StageX portable and easy to reproduce on all AMD based systems
-
-The only available target at the moment is AMD.
-
----
-
-# **Common open source software**
-
-StageX supports 100+ packages, with a focus on supporting software commonly used by developers
-
-Some of the currently available packages include: `curl`, `rust`, `git`, `go`, `bash`, `tofu`...
-
-If you are interested in additionally software being added feel free to open a PR or let us know what you would like to see added.
-
----
-
-# **Full source bootstrapped from Stage 0**
-
-The StageX compiler and all libraries necessary to build software are themselves fully bootstrapped and deterministic
-
-Bootstrapped - built up from "nothing" in order to allow verification of how the compiler is built - ensuring there is no malicious code added to it at any point.
-
-Ken Thompson describes the risk of using a compiler which can't be verified to be trustworthy in his seminal paper "Reflections on Trusting Trust"
-
----
-
-# **OK, So What?**
-
-There is an entire family of supply chain vulnerabilities which can be eliminated by using StageX
-
-By reducing the number of dependencies needed to run and build software, we remove unnecessary software which can act as an entry point for malicious software such as malware
-
-For example, if using Debian as a base for `rust`, one ends up using **232 dependencies**, where as StageX only requires **4 dependencies**
-
----
-
-Additionally, there has not been a simple way to verify that a compiler is trusted.
-
-This is because compilers are used to build other compilers, and for a long time, we lost the ability to build up a compiler toolchain from "nothing"
-
-StageX allows us to bootstrap the compiler toolchain, making it easy to verify that no malicious code was introduced at any point, by reviewing the code, and it also does so in a deterministic manner, which makes it simple to further verify the integrity of the binary
-
----
-
-# **What's Next?**
-
-Packaging more software
-
-Adding additional container runtimes like Podman and Kaniko
-
-Adding additional chip architecture support such as ARM and RISC-V
-
----
-
-# **Links**
-
-**Presenter**: <your_name>
-
-**Matrix Chat**: #stagex:matrix.org
-
-**Git Repo**: https://codeberg.org/stagex/stagex
-
-Big thank you to sponsors who have supported the development of this project:
-
-**Turnkey, Distrust, Mysten Labs**
-
-
-