https://media.ccc.de/c/asg2026 This feed contains all events from asg2026 as mp3 see video outro Wed, 30 Sep 2026 13:36:17 -0000 https://static.media.ccc.de/media/events/all_systems_go/2026/logo.png https://media.ccc.de/c/asg2026 https://media.ccc.de/v/all-systems-go-2026-391-measured-boot-in-nixos-other-systemd-updates This talk will present the newest updates and advancements in NixOS related to Secure & Measured Boot. It will take a look at what we have achieved this far, what issues we have come across, what we would like to see from the ecosystem, and what we are working towards next. Additionally, it will go over some other exciting things that happened related to systemd in NixOS. Key advancements: - [Support for Measured Boot via systemd-pcrlock in Lanzaboote](https://github.com/nix-community/lanzaboote/pull/564) (the boot security toolkit for NixOS) - [Support for Boot Counting in Lanzabooote](https://github.com/nix-community/lanzaboote/pull/477) - [Removed most patches from systemd (18 -> 6)](https://github.com/NixOS/nixpkgs/pull/488508) and added a patch policy that prohibits most new patches. - [systemd initrd is now the default](https://github.com/NixOS/nixpkgs/pull/435781) Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/QDB7AL/ Wed, 30 Sep 2026 12:25:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_mp3.mp3?1790773774 f00ce030-06a4-5753-a902-837a0acc2aa6 2026-09-30T12:25:00+02:00 Niklas Sturm No 391, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 This talk will present the newest updates and advancements in NixOS related to Secure & Measured Boot. It will take a look at what we have achieved this far, what issues we have come across, what we would like to see from the ecosystem, and what we are working towards next. Additionally, it will go over some other exciting things that happened related to systemd in NixOS. Key advancements: - [Support for Measured Boot via systemd-pcrlock in Lanzaboote](https://github.com/nix-community/lanzaboote/pull/564) (the boot security toolkit for NixOS) - [Support for Boot Counting in Lanzabooote](https://github.com/nix-community/lanzaboote/pull/477) - [Removed most patches from systemd (18 -> 6)](https://github.com/NixOS/nixpkgs/pull/488508) and added a patch policy that prohibits most new patches. - [systemd initrd is now the default](https://github.com/NixOS/nixpkgs/pull/435781) Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/QDB7AL/ 00:23:59 https://media.ccc.de/v/all-systems-go-2026-395-do-users-actually-want-a-trusted-immutable-os-lessons-from-the-industry Recent years have spurred much discussion in Linux communities about the idea of building an OS that is both Trusted and Immutable. While successful in many ways, attempts to implement these ideas have created numerous sharp edges for end users. At the same time, these initiatives bear many advantages for the ecosystem's push towards becoming more reliable, accessible, and consumable. What lessons can we take from other OS vendors to improve user experience and accelerate adoption? Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/R8XMRT/ Wed, 30 Sep 2026 12:25:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_mp3.mp3?1790773488 c6f8d047-d6a3-5a25-9d87-6c1f487590bc 2026-09-30T12:25:00+02:00 Katie Miller No 395, 2026, asg2026, Galerie, asg2026-eng, asg2026, Day 1 Recent years have spurred much discussion in Linux communities about the idea of building an OS that is both Trusted and Immutable. While successful in many ways, attempts to implement these ideas have created numerous sharp edges for end users. At the same time, these initiatives bear many advantages for the ecosystem's push towards becoming more reliable, accessible, and consumable. What lessons can we take from other OS vendors to improve user experience and accelerate adoption? Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/R8XMRT/ 00:21:41 https://media.ccc.de/v/all-systems-go-2026-390-systemd-round-table Let's have an open discussion with systemd developers who are at ASG and users in the audience. We will open with the developers saying what they plan to work on in the near future, and then allow questions / comments from the audience. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/RN9E3E/ Wed, 30 Sep 2026 11:55:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-390-eng-systemd_round_table_mp3.mp3?1790770717 efb38d7d-3ebb-5e3e-8e8d-60a97940c534 2026-09-30T11:55:00+02:00 Luca Boccassi, Zbigniew Jędrzejewski-Szmek, Lennart Poettering, Daan De Meyer No 390, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 Let's have an open discussion with systemd developers who are at ASG and users in the audience. We will open with the developers saying what they plan to work on in the near future, and then allow questions / comments from the audience. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/RN9E3E/ 00:26:42 https://media.ccc.de/v/all-systems-go-2026-409-moonforge-making-yocto-easy-to-assemble The Yocto project contains multitudes, and as such it contains the ability to create a modern, image based, integrator friendly operating system, taking advantage of various layers of tooling for hardware and feature support. Moonforge is the result of the work done by Igalia in this space, and it focuses on making it easy to create, build, test, deploy, and update a OS image for multiple products and verticals. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/HNUWBK/ Wed, 30 Sep 2026 11:55:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_mp3.mp3?1790770086 6a8ae828-3791-5ceb-a655-b8bc6366533d 2026-09-30T11:55:00+02:00 Emmanuele Bassi, Martín Abente Lahaye No 409, 2026, asg2026, Galerie, asg2026-eng, asg2026, Day 1 The Yocto project contains multitudes, and as such it contains the ability to create a modern, image based, integrator friendly operating system, taking advantage of various layers of tooling for hardware and feature support. Moonforge is the result of the work done by Igalia in this space, and it focuses on making it easy to create, build, test, deploy, and update a OS image for multiple products and verticals. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/HNUWBK/ 00:23:52 https://media.ccc.de/v/all-systems-go-2026-389-systemd-state-of-the-project Same as every year, a lot has happened in the systemd project since last year's ASG. We released multiple versions, packed with new components and features. This talk will provide an overview of these changes, commenting on successes and challenges, and a sneak peak at what lies ahead. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BTLLGC/ Wed, 30 Sep 2026 11:25:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-389-eng-systemd_state_of_the_project_mp3.mp3?1790765809 e8f38a6b-69e4-5d5e-82bb-9041d0331099 2026-09-30T11:25:00+02:00 Luca Boccassi, Zbigniew Jędrzejewski-Szmek No 389, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 Same as every year, a lot has happened in the systemd project since last year's ASG. We released multiple versions, packed with new components and features. This talk will provide an overview of these changes, commenting on successes and challenges, and a sneak peak at what lies ahead. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/BTLLGC/ 00:22:11 https://media.ccc.de/v/all-systems-go-2026-413-image-based-modular-deployment-for-large-teams-in-embedded-systems The image based Linux vision is clear: immutable system images, declarative composition, no imperative package installation at runtime. But what happens when you need dozens of independently deployable application modules on the same device, each owned by a different team in a large enterprise, each on its own release cadence, while keeping the root filesystem untouched? We built a modular deployment system for production Linux devices that takes the image based philosophy to its logical conclusion: every module is a read only ext4 filesystem image, built deterministically at build time, deployed to its own A/B partition with zero installation, and managed entirely through systemd transient services. No unit files on the rootfs. No package manager on the device. No post deploy scripts. The image is the truth. On the packaging side, we use deterministic ext4 creation with constant timestamps to produce (mostly) reproducible images regardless of build environment. This reproducibility directly enables efficient delta based OTA: because the on device image is read only and byte identical to what was built, we can chunk-diff against it and deliver only changed blocks critical for constrained networks. On the runtime side, a oneshot service mounts each module and starts it via systemd-run as a transient service inheriting automatic restart, cgroup resource control, and clean lifecycle semantics without ever writing a .service file to disk. We deliberately rejected the alternative of modules shipping their own unit files precisely because it violates the principle that deployment must not modify the root filesystem. Transient services give us the systemd machinery we need while preserving an immutable rootfs compatible with dm-verity. Modules are fully isolated: separate uid/gid, sandboxed filesystem access, dedicated persistent storage, and communication exclusively through a formal interface (gRPC unix domain sockets in our case). Each module treats every other module as a remote server: no hard startup dependencies, no shared state, no assumption that any other module is even present on the same device The talk will cover: * Applying image based Linux principles at the application module level, not just the OS * Packaging modules as (mostly) reproducible, read only ext4 images with deterministic tooling * How image based module packaging enables per-module automated testing: deploying test harnesses as modules themselves, composing versioned module sets for deterministic integration testing, and unlocking independent CI/CD pipelines per team * Why deb/rpm, Flatpak, and AppImage each fail for independently deployable A/B modules * Delta-based OTA delivery that exploits immutable images for chunk-level diffing * systemd transient services as a module lifecycle manager: all the benefits of systemd, none of the rootfs side effects * Per-module sandboxing, cgroup isolation, and gRPC-only IPC * Lessons from production: independently updating 40+ modules without device reboot Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLKVKW/ Wed, 30 Sep 2026 11:25:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_mp3.mp3?1790765773 9cbe8d11-14a1-5a9d-b7c9-a7e7a8723da2 2026-09-30T11:25:00+02:00 Corin Rypkema, Mike Sandige, Gopal Paudel No 413, 2026, asg2026, Galerie, asg2026-eng, asg2026, Day 1 The image based Linux vision is clear: immutable system images, declarative composition, no imperative package installation at runtime. But what happens when you need dozens of independently deployable application modules on the same device, each owned by a different team in a large enterprise, each on its own release cadence, while keeping the root filesystem untouched? We built a modular deployment system for production Linux devices that takes the image based philosophy to its logical conclusion: every module is a read only ext4 filesystem image, built deterministically at build time, deployed to its own A/B partition with zero installation, and managed entirely through systemd transient services. No unit files on the rootfs. No package manager on the device. No post deploy scripts. The image is the truth. On the packaging side, we use deterministic ext4 creation with constant timestamps to produce (mostly) reproducible images regardless of build environment. This reproducibility directly enables efficient delta based OTA: because the on device image is read only and byte identical to what was built, we can chunk-diff against it and deliver only changed blocks critical for constrained networks. On the runtime side, a oneshot service mounts each module and starts it via systemd-run as a transient service inheriting automatic restart, cgroup resource control, and clean lifecycle semantics without ever writing a .service file to disk. We deliberately rejected the alternative of modules shipping their own unit files precisely because it violates the principle that deployment must not modify the root filesystem. Transient services give us the systemd machinery we need while preserving an immutable rootfs compatible with dm-verity. Modules are fully isolated: separate uid/gid, sandboxed filesystem access, dedicated persistent storage, and communication exclusively through a formal interface (gRPC unix domain sockets in our case). Each module treats every other module as a remote server: no hard startup dependencies, no shared state, no assumption that any other module is even present on the same device The talk will cover: * Applying image based Linux principles at the application module level, not just the OS * Packaging modules as (mostly) reproducible, read only ext4 images with deterministic tooling * How image based module packaging enables per-module automated testing: deploying test harnesses as modules themselves, composing versioned module sets for deterministic integration testing, and unlocking independent CI/CD pipelines per team * Why deb/rpm, Flatpak, and AppImage each fail for independently deployable A/B modules * Delta-based OTA delivery that exploits immutable images for chunk-level diffing * systemd transient services as a module lifecycle manager: all the benefits of systemd, none of the rootfs side effects * Per-module sandboxing, cgroup isolation, and gRPC-only IPC * Lessons from production: independently updating 40+ modules without device reboot Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/VLKVKW/ 00:27:55 https://media.ccc.de/v/all-systems-go-2026-394-proposal-for-tpm2-fido2-enrollment-in-systemd User space based Full Disk Encryption in openSUSE is old news. We already can set up FDE installations using the systemd toolset. This allows us to use traditional passwords, the TPM2 to validate the status before mounting the encrypted device or a FIDO2 key to validate the presence of a token owned by authorized users. To increase the security, in Tumbleweed, we recommend combining both TPM2 and a password (TPM2+PIN). This guarantees the system is in a healthy state and the user has the correct authorization, but it still doesn't support a combination of TPM2 and FIDO2 keys. To fix this issue, we are proposing a new enrollment method in systemd: TPM2+FIDO2. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/SD3X9L/ Wed, 30 Sep 2026 10:45:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_mp3.mp3?1790764809 23b0213c-cfe6-5daf-a7f9-dd6bb7cafcec 2026-09-30T10:45:00+02:00 Alberto Planas Dominguez No 394, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 User space based Full Disk Encryption in openSUSE is old news. We already can set up FDE installations using the systemd toolset. This allows us to use traditional passwords, the TPM2 to validate the status before mounting the encrypted device or a FIDO2 key to validate the presence of a token owned by authorized users. To increase the security, in Tumbleweed, we recommend combining both TPM2 and a password (TPM2+PIN). This guarantees the system is in a healthy state and the user has the correct authorization, but it still doesn't support a combination of TPM2 and FIDO2 keys. To fix this issue, we are proposing a new enrollment method in systemd: TPM2+FIDO2. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/SD3X9L/ 00:21:47 https://media.ccc.de/v/all-systems-go-2026-407-bridging-the-varlink-gap Systemd provides a growing set of very useful varlink APIs. With the new Rust-based varlink-http-bridge, it is possible to expose any number of them over the network securely via https/websockets, including over vsock, with all of the interesting varlink features like "more" support or "protocol-upgrade" support. This presentation gives an overview of why varlink and websockets are such a good fit, why the varlink-http-bridge implementation is mostly just a transparent byte proxy, and how it plugs into varlinkctl seamlessly to make networked varlinkctl calls "just work". It also explains the security model and the plans for the future. The project lives in https://github.com/systemd/varlink-http-bridge. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/WDRTYW/ Wed, 30 Sep 2026 10:15:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-407-eng-Bridging_the_varlink_gap_mp3.mp3?1790764535 f859278b-e2af-5765-a085-756644211b26 2026-09-30T10:15:00+02:00 Michael Vogt No 407, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 Systemd provides a growing set of very useful varlink APIs. With the new Rust-based varlink-http-bridge, it is possible to expose any number of them over the network securely via https/websockets, including over vsock, with all of the interesting varlink features like "more" support or "protocol-upgrade" support. This presentation gives an overview of why varlink and websockets are such a good fit, why the varlink-http-bridge implementation is mostly just a transparent byte proxy, and how it plugs into varlinkctl seamlessly to make networked varlinkctl calls "just work". It also explains the security model and the plans for the future. The project lives in https://github.com/systemd/varlink-http-bridge. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/WDRTYW/ 00:25:55 https://media.ccc.de/v/all-systems-go-2026-434-provisioning-and-deployment-mechanisms-in-systemd In recent systemd releases we substantially improved the tooling for provisioning and deploying operating systems with systemd. For example, systemd-sysinstall, systemd-sysupdate, credentials, systemd-firstboot, systemd-stub's parameterization logic, systemd-confext, systemd-imds, systemd-import all are relevant components for getting a node up and running with the right configuration, securely and robustly. In this talk I'd like to explain the current landscape, and how the various components matter in various scenarios, and how they fit together. I'll also discuss what's next, what's missing, and where we should be going with all this. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/NLRDPH/ Wed, 30 Sep 2026 09:30:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_mp3.mp3?1790764239 1838a8da-6c04-5fea-aedb-d86fbe7561ca 2026-09-30T09:30:00+02:00 Lennart Poettering No 434, 2026, asg2026, Loft, asg2026-eng, asg2026, Day 1 In recent systemd releases we substantially improved the tooling for provisioning and deploying operating systems with systemd. For example, systemd-sysinstall, systemd-sysupdate, credentials, systemd-firstboot, systemd-stub's parameterization logic, systemd-confext, systemd-imds, systemd-import all are relevant components for getting a node up and running with the right configuration, securely and robustly. In this talk I'd like to explain the current landscape, and how the various components matter in various scenarios, and how they fit together. I'll also discuss what's next, what's missing, and where we should be going with all this. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/NLRDPH/ 00:41:20 https://media.ccc.de/v/all-systems-go-2026-414-attezt-device-attestation-pkcs11-and-acme IETF is standardizing a new ACME challenge, `device-attest-01`, which allows organizations to provision device bound certificates to machines, and enables machines to present signing certificates that can't be extracted out of machines they where intended for. This is useful for cases where you want to provide reverse proxies with mTLS with a strong sense of device identity. attezt is intended to be a suite of tools to work the new `device-attest-01` ACME challenges for Linux. It provides an ACME client, an attestation server with (simple) support for inventory systems and a PKCS11 agent which together enables the support of this ACME challenge on Linux. This talk will give an introduction to the new ACME challenge, a quick rundown of how an attestation server works and how attezt works. https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ https://github.com/Foxboron/attezt Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/8XRBTA/ Wed, 30 Sep 2026 10:15:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_mp3.mp3?1790763072 23d6c6b3-8a6b-5a07-8531-d9bab98c051b 2026-09-30T10:15:00+02:00 Morten Linderud No 414, 2026, asg2026, Galerie, asg2026-eng, asg2026, Day 1 IETF is standardizing a new ACME challenge, `device-attest-01`, which allows organizations to provision device bound certificates to machines, and enables machines to present signing certificates that can't be extracted out of machines they where intended for. This is useful for cases where you want to provide reverse proxies with mTLS with a strong sense of device identity. attezt is intended to be a suite of tools to work the new `device-attest-01` ACME challenges for Linux. It provides an ACME client, an attestation server with (simple) support for inventory systems and a PKCS11 agent which together enables the support of this ACME challenge on Linux. This talk will give an introduction to the new ACME challenge, a quick rundown of how an attestation server works and how attezt works. https://datatracker.ietf.org/doc/draft-ietf-acme-device-attest/ https://github.com/Foxboron/attezt Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/8XRBTA/ 00:23:47 https://media.ccc.de/v/all-systems-go-2026-445-particleos-in-action At Axis, we are always interested in standard technologies and how we can align with them. With that in mind, we have been studying the principles and ideas behind ParticleOS. In this session, we will build ParticleOS live with mkosi and boot it in a VM. We will look into the provisioning steps of such a machine and the changes in the OS image layout. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/L3KZRV/ Wed, 30 Sep 2026 10:45:00 +0200 https://cdn.media.ccc.de/events/all_systems_go/2026/mp3/asg2026-445-eng-ParticleOS_in_action_mp3.mp3?1790764792 979df6f7-685d-5c80-9a2d-0370c9c6c180 2026-09-30T10:45:00+02:00 Umut Tezduyar Lindskog No 445, 2026, asg2026, Galerie, asg2026-eng, asg2026, Day 1 At Axis, we are always interested in standard technologies and how we can align with them. With that in mind, we have been studying the principles and ideas behind ParticleOS. In this session, we will build ParticleOS live with mkosi and boot it in a VM. We will look into the provisioning steps of such a machine and the changes in the OS image layout. Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/ about this event: https://cfp.all-systems-go.io/all-systems-go-2026/talk/L3KZRV/ 00:22:53 media.ccc.de / RSS 0.3.3 CCC media team media@c3voc.de CCC media team No CCC Congress Hacking Security Netzpolitik A wide variety of video material distributed by the CCC. All content is taken from cdn.media.ccc.de and media.ccc.de A wide variety of video material distributed by the Chaos Computer Club. This feed contains all events from asg2026 as mp3