## Verification of OS artifacts without stateful keyrings <p>All Systems Go! 2025</p> <p>David Runge</p>

### Overview * [OS artifacts 🗿](#os-artifacts-🗿) * [Keyrings 🗝️](#stateful-keyrings-🗝️) * [Unifying concepts ✍️](#unifying-concepts-✍️) * [Example 📄](#example-📄) * [Next steps 👣](#next-steps-👣)

### About * Freelance software developer * Arch Linux Package Maintainer (2017)/ Developer (2019)/ Main Signing Key (2021) * Rust, Python, infrastructure, packaging, installation process

### OS artifacts 🗿

### Packaging * Package files * Repository metadata

### OS updates * OS images/virtual machines * installation media

### Keyrings 🗝️ Case study: OpenPGP

### Stateful technology * GnuPG's `gpg` * Sequoia-PGP's `sq`

### Per-application locations * package managers * system updaters * image creation tools

### Payloads and signatures * what is signed? * in what role is a signature created? * for what context is something signed? * is there a Public Key Infrastructure (PKI) with a hierarchy?

### Example: `systemd-sysupdate` * uses `/usr/lib/systemd/import-pubring.pgp` or `/etc/systemd/import-pubring.pgp` as keyring * downloads update payloads, checksum file and OpenPGP signature * runs `gpg` to import an application-specific keyring in a temporary location * verifies the checksum file with the OpenPGP signature using `gpg`

### Example: `pacman` * uses `/etc/pacman.d/gnupg/` as keyring * downloads package file and OpenPGP signature * uses `gpgme` as root to verifiy the package file with the OpenPGP signature

### Other technologies * CMS/PKCS#7 * minisign * signify * SSH

## Unifying concepts ✍️

## Similarities between technologies * Digital signatures are created in a specific role, for a context * Sometimes there are one or more trust-anchors * Authentication without being tied to OAuth provider * No unifying structure exists

## Enter VOA 🔥 * [File Hierarchy for the **V**erification of **O**S **A**rtifacts](https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/) * Directory structure for cryptographic verifiers, with overrides (e.g. _/usr/share/voa/_ -> _/usr/local/share/voa/_ -> _/run/voa/_ -> _/etc/voa/_) * Encodes the _origin_, _purpose_ and _context_ of each verifier * Allows for evaluation of trust-anchor relationships * Multi-technology approach

## Hierarchy example ```shell . └── debian:12 └── packages └── default └── openpgp └── f1d2d2f924e986ac86fdf7b36c94bcdf32beec15.openpgp ``` * _os_: follows [os-release](https://www.freedesktop.org/software/systemd/man/latest/os-release.html), e.g. _debian:13_ * _purpose_: What purpose are verifiers used for (e.g. "packages")? * _context_: Which context are verifiers used in (e.g. "repo-name")? * _technology_: The technology identifier (currently only "openpgp")

## Goals 🎯 * Directory structure that encodes semantics * Easy distribution of verifiers * Easy, stateless access for users * Override semantics * Easy switching of technology

## Example 📄

## Next steps 👣

## Existing OpenPGP technology 🚀 * Use of trust-anchors * Develop a configuration file format (usable by all technologies)

## More technologies ✨ * Integrate PoC for CMS/PKCS#7 * Find interested people to fully specify and start implementing minisign, signify, SSH

## Test suite ✅ * Break out dedicated test suite for further implementations

## Slides <img src="img/slides-link.png"></img>

## Thanks * [Sovereign Tech Agency](https://www.sovereign.tech/tech/arch-linux-package-management) * Heiko Schäfer ([@hko@floss.social](https://floss.social/@hko)) * Reviewers, implementers (Anton Hvornum, Arthur Gautier, Daniel Kahn Gilmor, Lennart Poettering, Miroslav Suchý, Morten Linderud, Wiktor Kwapisiewicz)

## Contact * [VOA specification](https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/) * [VOA reference implementation](https://crates.io/crates/voa) 🦀 * [David Runge \<dave@sleepmap.de\>](mailto:dave@sleepmap.de) * [@dvzrv@chaos.social](https://chaos.social/@dvzrv)

## ???

## Kthxbye 👋