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)
|
![bg left:40% 80%](img/stagex-logo.png)
|
||||||
|
|
||||||
# Bootstrapping Reproducibility with StageX
|
# Bootstrapping Reproducibility with StageX
|
||||||
|
@ -80,12 +87,6 @@ ENTRYPOINT ["/usr/bin/mnemonicgen"]
|
||||||
Approach the development of a secure toolchain by ensuring each component uses
|
Approach the development of a secure toolchain by ensuring each component uses
|
||||||
exactly what it needs to build - no more, no less.
|
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
|
<!-- Speaker notes
|
||||||
Most Linux distributions are built for *compatibility* rather than *security*.
|
Most Linux distributions are built for *compatibility* rather than *security*.
|
||||||
This results in a dramatic increase of attack surface area of an operating
|
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
|
environments with a minimal footprint to eliminate attack surface area. Each
|
||||||
component of the toolchain installs only what it needs, and only packages what
|
component of the toolchain installs only what it needs, and only packages what
|
||||||
it builds, resulting in a decreased attack surface.
|
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 |
|
| 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
|
<!-- NOTE: "Rust deps" is the amount of dependencies required to build a Rust
|
||||||
hello world -->
|
hello world -->
|
||||||
|
|
||||||
<!--
|
<!---
|
||||||
|
-- Unable to confirm the following:
|
||||||
| Guix | 1 Human | Glibc | Yes | Yes | 4 |
|
| Guix | 1 Human | Glibc | Yes | Yes | 4 |
|
||||||
| Nix | 1 Bot | Glibc | Partial | Mostly | 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
|
<!-- Add a link to a script that confirms/reproduces the dependency count for
|
||||||
building Rust hello world -->
|
building Rust hello world -->
|
||||||
|
@ -145,15 +152,17 @@ COPY --from=build /app/target/$TARGET/release/hello /usr/bin/hello
|
||||||
CMD ["/usr/bin/hello"]
|
CMD ["/usr/bin/hello"]
|
||||||
```
|
```
|
||||||
|
|
||||||
<!-- TODO: make pallets a thing, test this. Include RUSTFLAGS to make static in
|
|
||||||
the pallet -->
|
|
||||||
|
|
||||||
<!-- Speaker notes
|
<!-- Speaker notes
|
||||||
In this example, note how we are only pulling in Rust and the dependencies
|
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
|
required to invoke Rust. If we're using external libraries - such as Nettle and
|
||||||
attack surface when compiling software.
|
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:
|
# 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
|
* 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
|
package locally and sign the containers with an OCI-compliant signature using
|
||||||
well-known OpenPGP keys.
|
well-known OpenPGP keys.
|
||||||
|
---
|
||||||
-->
|
-->
|
||||||
|
|
||||||
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
|
<!-- TODO: talk about bootstrapping, incl. corrupt compilers in distro
|
||||||
|
@ -182,17 +192,30 @@ toolchain -->
|
||||||
|
|
||||||
<!-- https://distrowatch.com/images/other/distro-family-tree.png -->
|
<!-- 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
|
# 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
|
Put some kind of graphic here to explain the association between images
|
||||||
and multisig, each image being signed by at least two
|
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
|
# 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.
|
> - 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.
|
> - 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
|
We can see that the compromise occurred because the threat actors infiltrated
|
||||||
the network and replaced source code files during build time.
|
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.
|
* StageX packages the software you're already using, securely.
|
||||||
* By leveraging Docker, we avoid mixing package managers and build contexts.
|
* 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
|
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
|
arbitrary execution of `setup.py` or post-download scripts, and by using Docker
|
||||||
as our package manager, we avoid all forms of spontaneous execution.
|
as our package manager, we avoid all forms of spontaneous execution.
|
||||||
|
|
||||||
All StageX software is built deterministically, meaning you can be sure your
|
All StageX software is built deterministically, meaning you can be sure all
|
||||||
Software Bill Of Materials hasn't been tampered with. Because StageX provides a
|
components listed in your Software Bill Of Materials hasn't been tampered with.
|
||||||
toolchain for you to build your software in the same manner, your software can
|
Because StageX provides a toolchain for you to build your software in the same
|
||||||
be sooper dooper pooper scooper secure.
|
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
|
**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:
|
Big thank you to sponsors who have supported the development of this project:
|
||||||
|
|
||||||
**Turnkey, Distrust, Mysten Labs**
|
**Turnkey, Distrust, Mysten Labs**
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
Loading…
Reference in New Issue