make speaker notes more legible, update for marp 4.0.0
This commit is contained in:
parent
0da5e02d3f
commit
a1b3904670
118
stagex/index.md
118
stagex/index.md
|
@ -6,6 +6,13 @@ backgroundColor: #fff
|
|||
|
||||
<!-- __ -->
|
||||
|
||||
<!-- Changed in Marp 4.0.0. Re-center -->
|
||||
<style>
|
||||
section.lead {
|
||||
display: flex;
|
||||
}
|
||||
</style>
|
||||
|
||||
![bg left:40% 80%](img/stagex-logo.png)
|
||||
|
||||
# Bootstrapping Reproducibility with StageX
|
||||
|
@ -80,12 +87,6 @@ ENTRYPOINT ["/usr/bin/mnemonicgen"]
|
|||
Approach the development of a secure toolchain by ensuring each component uses
|
||||
exactly what it needs to build - no more, no less.
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
<!-- 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
|
||||
|
@ -93,9 +94,22 @@ 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 |
|
||||
|--------------|------------|-------|--------------|--------------|----------:|
|
||||
|
@ -108,18 +122,11 @@ it builds, resulting in a decreased attack surface.
|
|||
<!-- 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 |
|
||||
-->
|
||||
|
||||
<!--
|
||||
StageX is the first Linux multisig distribution, is one of two fully
|
||||
bootstrapped Linux distributions, is 100% reproducible and deterministic,
|
||||
and has an incredibly low amount of dependencies required to build Rust
|
||||
software.
|
||||
-->
|
||||
|
||||
--->
|
||||
|
||||
<!-- Add a link to a script that confirms/reproduces the dependency count for
|
||||
building Rust hello world -->
|
||||
|
@ -145,15 +152,17 @@ COPY --from=build /app/target/$TARGET/release/hello /usr/bin/hello
|
|||
CMD ["/usr/bin/hello"]
|
||||
```
|
||||
|
||||
<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
|
||||
the pallet -->
|
||||
|
||||
<!-- Speaker notes
|
||||
In this example, note how we are only pulling in Rust and the dependencies
|
||||
required to invoke Rust. We don't include anything extra, which reduces the
|
||||
attack surface when compiling software.
|
||||
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:
|
||||
|
@ -175,6 +184,7 @@ maintenance that is performed compared to most distributions. This includes:
|
|||
* 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.
|
||||
---
|
||||
-->
|
||||
|
||||
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
|
||||
|
@ -182,17 +192,30 @@ toolchain -->
|
|||
|
||||
<!-- https://distrowatch.com/images/other/distro-family-tree.png -->
|
||||
|
||||
<!-- TODO: libfakerand to act as the "why" -->
|
||||
<!--
|
||||
* Create modified compiler which injects libfakerand during build time
|
||||
* Use it to compile software from source, for example bitcoin core
|
||||
* Show that the wallet generated with bitcoin core is not random
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# 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.
|
||||
---
|
||||
-->
|
||||
|
||||
<!--
|
||||
Put some kind of graphic here to explain the association between images
|
||||
and multisig, each image being signed by at least two
|
||||
|
@ -212,25 +235,6 @@ digraph {
|
|||
}
|
||||
-->
|
||||
|
||||
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.
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
||||
# Common toolchain dependencies
|
||||
|
@ -312,7 +316,7 @@ According to: https://www.crowdstrike.com/blog/sunspot-malware-technical-analysi
|
|||
> - 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.
|
||||
|
||||
|
@ -348,7 +352,8 @@ If everyone builds stagex, everyone has to be compromised.
|
|||
|
||||
* StageX packages the software you're already using, securely.
|
||||
* By leveraging Docker, we avoid mixing package managers and build contexts.
|
||||
* Your software, as well as your SBOM, can all be built deterministically.
|
||||
* 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
|
||||
|
@ -358,10 +363,10 @@ 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 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.
|
||||
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.
|
||||
-->
|
||||
|
||||
---
|
||||
|
@ -376,7 +381,7 @@ Adding additional chip architecture support such as ARM and RISC-V
|
|||
|
||||
---
|
||||
|
||||
# **Links**
|
||||
# Links
|
||||
|
||||
**Matrix Chat**: #stagex:matrix.org
|
||||
|
||||
|
@ -385,6 +390,3 @@ Adding additional chip architecture support such as ARM and RISC-V
|
|||
Big thank you to sponsors who have supported the development of this project:
|
||||
|
||||
**Turnkey, Distrust, Mysten Labs**
|
||||
|
||||
|
||||
|
||||
|
|
Loading…
Reference in New Issue