Compare commits
5 Commits
master
...
ryansquare
| Author | SHA1 | Date |
|---|---|---|
 Ryan Heywood
|
40962a7fda
|
|
|
Ryan Heywood
|
3dcd7da30d
|
|
|
Ryan Heywood
|
0e2e49b859
|
|
 Anton Livaja
|
778774fe33
|
|
|
Ryan Heywood
|
beea47e1f6
|
|
|
@ -2,6 +2,5 @@
|
|||
|
||||
## Instructions
|
||||
|
||||
1. Install [`marp-cli`](https://github.com/marp-team/marp-cli)
|
||||
2. Run `marp <file.md>` to create an html file
|
||||
3. Open file using browser
|
||||
1. Install [`marp-cli`](#stagex:matrix.org)
|
||||
2. Run `marp <md_file.md>` to create an html file
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 27 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 29 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 76 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 704 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
|
|
@ -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
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Sign / Verify
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## Diffie Helman Key Exchange
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
## 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>`
|
||||
|
|
@ -1,457 +0,0 @@
|
|||
---
|
||||
_class: lead
|
||||
paginate: true
|
||||
backgroundColor: #fff
|
||||
---
|
||||
|
||||
<!-- Speaker notes
|
||||
|
||||
Hey my name is Lance, a co-founder of Distrust, a security auditing and engineering company that specializes in working with high risk organizations that can't afford to trust any single computer or person. I also founded #!, a security, privacy, and digital sovereginity focused digital hackerspace built around classic public access linux systems. I also have architected and built a lot of software you have may have seen or used at one point or another over the years. I am not proud of most of it. I only do open source things now.
|
||||
|
||||
You have possibly seen articles of some of my various dumb publicity stunts to try to get people to care about privacy rights and supply chain security. Sorry. The japanese robot hotel one was funny though.
|
||||
|
||||
I now work with a team of people smarter than me at Distrust and the wider open source community and we are working on actually -solving- supply chain trust problems, because me complaining about them for years didn't work. One of those projects we are talking about today, Stagex!
|
||||
|
||||
Also, many have heard me preach the 10/20/30 rules of presentations.
|
||||
|
||||
Let's break all those rules real quick as we have a bunch of slides I want to get through fast because giving presentations terrifies me, which is why I dropped out of school.
|
||||
|
||||
You can read the markdown file I generated these slides from later.
|
||||
|
||||
I am in this for the interesting part. Questions, discussion, and debate!
|
||||
|
||||
Here goes.
|
||||
|
||||
A lot of us build software responsible for protecting immense amount of financal value, important secrets, or even human lives.
|
||||
|
||||
When you really boil it all down, there is almost always at least one person you can point at with the power to tamper with the software that builds your software without anyone noticing.
|
||||
|
||||
That person is often loves their family, likes money, or does not have good opsec. Or maybe they just let a personal email domain expire which allowed any rando to take over their release responsibilities. Several thousand supply chain critical domans are up for grabs right now by the way. I bought a few. It's easy.
|
||||
|
||||
In this example here, imagine someone simply placed libfakerand (shameless to my co-founder Anton) in a popular container image. After all the world runs on containers today, and almost none of them are signed or even gated with hardware multi factor auth.
|
||||
|
||||
|
||||
Let's TLDR the problem.
|
||||
|
||||
|
||||
And now let's TLDR the solution we landed on, with some buzzword bingo
|
||||
|
||||
Don't worry, the rest of the slides are mostly just me breaking this down.
|
||||
|
||||
So going back to what I was saying earlier, people use containers today for basically everything.
|
||||
|
||||
Most distros started before the OCI standard was a thing, which is why most Linux distros approach to containers feels like a hastily retrofitted bastardization that walks back critical security choices in the name of broad adoption above all else.
|
||||
|
||||
We asked ourselves what would happen if we just used the OCI standard all the way down from the start. Could we just use that spec basically as-is with some creative patterns, and no package manager at all, and still end up with something declarative, easy to maintain, and reproducible, with a lot of properties we like about Nix and Guix for downstream reproducibility in end user projects?
|
||||
|
||||
It sounds like a drunk idea the spec authors never considered, but with the right patterns it works great.
|
||||
|
||||
Here is our actual BC package, which is a pretty typical example. Its pretty much just linux from scratch in containers.
|
||||
|
||||
Note that we force the hash-locking on the dependencies at build-time to be whatever is in the same git tree
|
||||
|
||||
But now for a harder problem. What toolchain do we trust enough to build our toolchain that requires trusting no single party?
|
||||
|
||||
We didn't have an answer until we stumbled upon the Bootstrappable Builds project. Build everything from zero and get the same results no matter what host OS you are using. They had only gotten it all working a month before we started stagex. Perfect timing.
|
||||
|
||||
This concept is called full source bootstrapping.
|
||||
|
||||
There are plenty of talks about this, so I'll just TL;DR the strategy we landed on.
|
||||
|
||||
We start with a tiny self hosting program written in hex0, that is just enough code to build itself, and a slightly more sophisticated version of itself, hex1, and so on, until we have a basic shell called Kaem. This set of binaries is called stage0, and often referred to as seed binaries, which everything else grows from.
|
||||
|
||||
In stage1 we use the live bootstrap project to speed run compiling snapshots of 150 stages of open software toolchains from 1970s era to modern x86 GCC.
|
||||
|
||||
In stage2 we build a cross compiler bridging from x86 to our target architecture
|
||||
|
||||
In stage3 we build a standalone native nano linux toolchain with busybox for our target architecture
|
||||
|
||||
With several people doing this and getting the same bit for bit identical results and signing them, we finally have a reproducible base image we can trust to build everything else deterministically.
|
||||
|
||||
-now- we are in really good shape to build almost any software reproducibly.
|
||||
|
||||
Reproducibility itself is probably the least new of anything here, but we do have a very strict definition.
|
||||
|
||||
Not having to support desktop users helps a lot
|
||||
|
||||
But for us reproducibilty is mostly about accountability and tamper evidence. We don't want you to trust some random build server realy reproduced something. You should have a way to verify multiple independent humans did it, and ideally do it in a way that uses standards so it is possible to set your own trust thresholds before a package of ours can run in your environment.
|
||||
|
||||
Most distros opt for a centralized trust scope with the whole world trusting one release engineer, or maybe worse, a distributed model where every maintainer can do whatever they want with their own packages with no oversight.
|
||||
|
||||
We wanted decentralized trust, where we assume at least one member of the team is compromised or malicious at all times.
|
||||
|
||||
Thankfully the OCI spec has a policy system for multi-signing images that seemingly no one uses. Lets actually use it!
|
||||
|
||||
-->
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
<style>
|
||||
/* Changed in Marp 4.0.0. Re-center. */
|
||||
section.lead {
|
||||
display: flex;
|
||||
}
|
||||
|
||||
div.two-columns {
|
||||
column-count: 2;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
|
||||
# Easier supply chain security
|
||||
|
||||
A container-native, full-source-bootstrapped, reproducible, and multi-signed toolchain to build all the things.
|
||||
|
||||
---
|
||||
|
||||
# Do you know who built your base image?
|
||||
|
||||
```dockerfile
|
||||
FROM trusted/distro
|
||||
RUN pkg install openssl
|
||||
ENTRYPOINT ["/usr/bin/openssl"]
|
||||
CMD ["rand", "-hex", "12"]
|
||||
```
|
||||
|
||||
<hr />
|
||||
|
||||
<div class="two-columns">
|
||||
|
||||
<div>
|
||||
|
||||
```sh
|
||||
> docker build -t local/randtest -f Containerfile .
|
||||
|
||||
> docker run local/randtest
|
||||
|
||||
2a2a2a2a2a2a2a2a2a2a2a2a
|
||||
|
||||
> docker run local/randtest
|
||||
|
||||
2a2a2a2a2a2a2a2a2a2a2a2a
|
||||
```
|
||||
|
||||
Woops, someone included libfakerand!
|
||||
</div>
|
||||
|
||||
<div>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<!-- Include link to repo -->
|
||||
|
||||
|
||||
---
|
||||
|
||||
# Problem Statement
|
||||
|
||||
## Build software without expecting users to trust any single human or computer.
|
||||
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
<br />
|
||||
|
||||
We really didn't want to make yet another Linux distro.
|
||||
|
||||
Sadly, nothing we evaluated fit our threat model.
|
||||
|
||||
---
|
||||
|
||||
Let's first break down the buzzword bingo:
|
||||
<br />
|
||||
<br />
|
||||
|
||||
## Stagex is a container-native, full-source-bootstrapped, reproducible, and multi-signed toolchain to build all the things.
|
||||
|
||||
---
|
||||
# Container-native
|
||||
|
||||
- Most sysadmins today do everything in containers
|
||||
- Most release engineers today build everything in containers
|
||||
- OCI container spec solves the problems of most linux package managers
|
||||
- OCI syntax allows for very succinct and simple package definitions
|
||||
- OCI has many competing implementations, and this is a good thing!
|
||||
- OCI has official support for multiple signatures, and signing policies
|
||||
- Every stagex package is just an OCI layer, which can be hash locked
|
||||
|
||||
---
|
||||
### Our actual BC "package" is just OCI layers all the way down
|
||||
|
||||
```dockerfile
|
||||
FROM scratch AS build
|
||||
ARG VERSION
|
||||
COPY --from=stagex/core-busybox . /
|
||||
COPY --from=stagex/core-gcc . /
|
||||
COPY --from=stagex/core-binutils . /
|
||||
COPY --from=stagex/core-make . /
|
||||
COPY --from=stagex/core-musl . /
|
||||
COPY --from=fetch . .
|
||||
RUN tar -xf sed-${VERSION}.tar.xz
|
||||
WORKDIR /sed-${VERSION}
|
||||
RUN --network=none <<-EOF
|
||||
set -eux
|
||||
./configure --prefix=/usr
|
||||
make -j "$(nproc)"
|
||||
make DESTDIR=/rootfs install
|
||||
EOF
|
||||
FROM stagex/core-filesystem AS package
|
||||
COPY --from=build /rootfs/ /
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
|
||||
# Full source bootstrapped
|
||||
|
||||
TL;DR: Solve Ken Thompsan's Trusting Trust problem:
|
||||
|
||||
- Stage 0: Bootstrap primitive binaries from 256 bytes of hex0
|
||||
- Stage 1: Bootstrap all the way up to x86 GCC
|
||||
- Stage 2: Build GCC cross compiler toolchain
|
||||
- Stage 3: Building a native hosted GCC toolchain
|
||||
- Stage X: Build whatever you want
|
||||
|
||||
|
||||
Only possible because of heroic work by the Bootstrappable Builds team!
|
||||
|
||||
---
|
||||
|
||||
### Stage0: Build bootstrap seeds with self hosting hex0 "compiler"
|
||||
|
||||
```hex
|
||||
0000000 457f 464c 0101 0301 0000 0000 0000 0000
|
||||
0000010 0002 0003 0001 0000 804c 0804 002c 0000
|
||||
0000020 0000 0000 0000 0000 0034 0020 0001 0000
|
||||
0000030 0000 0000 8000 0804 8000 0804 00b5 0000
|
||||
0000040 00b5 0000 0001 0000 0001 0000 5b58 315b
|
||||
0000050 6ac9 5805 cd99 5b80 6650 41b9 6602 c0ba
|
||||
0000060 6a01 5805 80cd 4299 3197 89ed 4ed6 895b
|
||||
0000070 6ae1 5803 80cd 8553 75c0 4005 db31 80cd
|
||||
0000080 018a 0a3c e574 f685 e475 233c df74 3b3c
|
||||
0000090 db74 302c 0a2c 0872 072c df24 073c ce73
|
||||
00000a0 e5c1 0404 010a f7c5 7cdf 89c3 8929 b0fb
|
||||
00000b0 cd04 eb80 00b4
|
||||
00000b5
|
||||
```
|
||||
|
||||
It makes more sense with comments:
|
||||
https://github.com/oriansj/stage0-posix-x86/blob/master/hex0_x86.hex0
|
||||
|
||||
---
|
||||
|
||||
### Stage1: Bootstrap up to x86 gcc toolchain from bootstrap seeds
|
||||
|
||||
It is basically building up from the 1970s all over again
|
||||
|
||||
- Step 1: hex0
|
||||
- Step 9: M0 C (cc_x86)
|
||||
- Step 19: scheme (GNU Mes)
|
||||
- Step 20: ~C99 C (Tinycc)
|
||||
- Step 56: perl 5x
|
||||
- Step 83: gcc 4x
|
||||
- Step 148: python 2x
|
||||
- Step 158: gcc 13x (still x86)
|
||||
|
||||
Full steps: https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
|
||||
|
||||
---
|
||||
|
||||
### Stage2: Pivot from x86 -> $TARGET cross toolchain
|
||||
|
||||
It is not that exciting.
|
||||
|
||||
- Step 1: Build cross binutils
|
||||
- Step 2: Build minimal cross gcc (without libgcc)
|
||||
- Step 3: Build libgcc against musl headers
|
||||
- Step 4: Build musl
|
||||
- Step 5: Build rest of gcc
|
||||
|
||||
---
|
||||
|
||||
### Stage3: Build native $TARGET toolchain
|
||||
|
||||
Also not that exciting.
|
||||
|
||||
- Step 1: Build musl
|
||||
- Step 2: Build binutils
|
||||
- Step 3: Build make
|
||||
- Step 4: Build gcc
|
||||
- Step 5: Build busybox
|
||||
|
||||
This covers "full source bootstrapped"
|
||||
|
||||
Now we can talk about what we mean by reproducible.
|
||||
|
||||
---
|
||||
|
||||
# Reproducible
|
||||
|
||||
- 100% reproducible with no compromises
|
||||
- Must be easy and doable at any time: Clone our repo and run "make"
|
||||
- We disagree with the metrics most distros use for reproducibility
|
||||
- Requiring a non-reproducible binary to acheive reproduction, is cheating
|
||||
- We build -everything- from 0. Rust, random firmware blobs in qemu. Everything.
|
||||
|
||||
<br />
|
||||
<br />
|
||||
|
||||
( In fairness, ignoring desktop use cases has made these goals a -lot- easier.)
|
||||
|
||||
---
|
||||
|
||||
# Multi-signed
|
||||
|
||||
* Centralized Trust is dangerous
|
||||
* Distributed Trust is maybe even more dangerous
|
||||
* We went with Decentralized trust: trust a quorum, not any individual.
|
||||
* Sign every commit with a hardware token
|
||||
* Sign every review with a hardware token
|
||||
* Sign every reproductions on diverse systems with a hardware token
|
||||
* Reproduce and submit your own signatures for the whole tree at any time!
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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; }"
|
||||
}
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Decentralized Trust
|
||||
|
||||
Multiple maintainers can each sign individual images, so OCI runtime policies
|
||||
can enforce _multiple_ signatures by maintainers to ensure no individual
|
||||
maintainer could have tampered with an image.
|
||||
|
||||
[](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; }"
|
||||
}
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
| Distro | Trust Model | OCI | Packaging | Bootstrapped | Reproducible |
|
||||
|-----------|---------------|-----------|--------------|--------------|--------------|
|
||||
| Stagex | Decentralized | Native | Declarative | Yes | Yes |
|
||||
| Guix | Distributed | Exported | Declarative | Yes | Mostly |
|
||||
| Debian | Distributed | Published | Imperative | No | Mostly |
|
||||
| Arch | Distributed | Published | Imperative | No | Mostly |
|
||||
| Nix | Centralized | Exported | Declarative | Partial | Mostly |
|
||||
| Yocto | Centralized | Exported | Source Only | No | Mostly |
|
||||
| Buildroot | Centralized | Exported | Source Only | No | Mostly |
|
||||
| Alpine | Centralized | Published | Imperative | No | No |
|
||||
| Fedora | Centralized | Published | Imperative | No | No |
|
||||
|
||||
---
|
||||
|
||||
# TL;DR: Give everyone a shorter path to better supply chain security
|
||||
<br />
|
||||
|
||||
### A reproducible full source bootstrapped Containerfile for a rust project:
|
||||
<br />
|
||||
|
||||
```dockerfile
|
||||
ARG RUST_VERSION
|
||||
FROM stagex/pallet-rust@${RUST_VERSION} AS build
|
||||
ADD src/ .
|
||||
ENV RUSTFLAGS='-C target-feature=+crt-static'
|
||||
RUN cargo build --release --target-dir .
|
||||
|
||||
FROM stagex/filesystem AS package
|
||||
COPY --from=build hello /usr/bin/hello
|
||||
CMD ["/usr/bin/hello"]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
|
||||
---
|
||||
|
||||
# Key Takeaways
|
||||
|
||||
* StageX packages the software you're already using, securely.
|
||||
* By leveraging OCI (Docker, podman, etc), we avoid mixing package managers and build contexts.
|
||||
* Your software, at every point in the bootstrapped toolchain, can all be built
|
||||
deterministically.
|
||||
|
||||
---
|
||||
|
||||
# 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
|
||||
* Crosschains: Cross compiler packages so you can target any arch from your native arch
|
||||
* Mirrors: Much more maintainable source/mirror management in review
|
||||
* Pallets: sets of deps to be imported/locked with one line
|
||||
* Boxes: Easily output stagex builds as bootable ISO images, firmware, packages for other distros, etc
|
||||
|
||||
---
|
||||
|
||||
# Links
|
||||
|
||||
**Matrix Chat**: #stagex:matrix.org
|
||||
|
||||
**Git Repo**: https://codeberg.org/stagex/stagex
|
||||
|
||||
**Slides**: https://git.distrust.co/public/presentations
|
||||
|
||||
**ReprOS**: https://codeberg.org/stagex/repros
|
||||
|
||||
**AirgapOS**: https://git.distrust.co/public/airgap
|
||||
|
||||
**EnclaveOS**: https://git.distrust.co/public/enclaveos
|
||||
|
||||
**Keyfork**: https://git.distrust.co/public/keyfork
|
||||
|
||||
Big thank you to sponsors who have supported the development of this project:
|
||||
|
||||
**Turnkey, Distrust, Mysten Labs**
|
||||
|
|
@ -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"]
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 37 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 329 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 117 KiB |
|
|
@ -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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
* 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
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 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?
|
||||
-->
|
||||
---
|
||||
|
||||
|
||||
<!--
|
||||
* 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
|
||||
|
||||
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
---
|
||||
-->
|
||||
|
||||
|
||||
|
||||
<!--
|
||||
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)
|
||||
|
||||
<!--
|
||||
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!
|
||||
|
|
@ -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"]
|
||||
|
|
@ -6,13 +6,9 @@ backgroundColor: #fff
|
|||
|
||||
<style>
|
||||
/* Changed in Marp 4.0.0. Re-center. */
|
||||
section.lead {
|
||||
display: flex;
|
||||
}
|
||||
|
||||
div.two-columns {
|
||||
column-count: 2;
|
||||
}
|
||||
section.lead {
|
||||
display: flex;
|
||||
}
|
||||
</style>
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
COPY --from=stagex/musl . /
|
||||
ENTRYPOINT ["/usr/bin/openssl"]
|
||||
CMD ["rand", "-hex", "12"]
|
||||
FROM rust
|
||||
ADD . /app
|
||||
WORKDIR /app
|
||||
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>
|
||||
|
||||
|
||||
|
||||
</div>
|
||||
|
||||
</div>
|
||||
|
||||
<!-- Include link to repo -->
|
||||
|
||||
<!--
|
||||
Loading…
Reference in New Issue