<?xml version="1.0" encoding="UTF-8"?>
<rdf:RDF xmlns="http://purl.org/rss/1.0/"
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:image="http://purl.org/rss/1.0/modules/image/"
  xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/"
  xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">
  <channel rdf:about="//media.ccc.de/updates.rdf">
    <title>Chaos Computer Club - last 100 events feed</title>
    <link>//media.ccc.de/</link>
    <description>Der Chaos Computer Club ist die größte europäische Hackervereinigung, und seit über 25 Jahren Vermittler im Spannungsfeld technischer und sozialer Entwicklungen.</description>
    <image rdf:resource="/images/frontend/feed-banner.png"/>
    <items>
      <rdf:Seq>
        <rdf:li resource="https://cdn.media.ccc.de/contributors/noname_ev/h264-sd/import-110780-deu-Warum_loescht_ue_in_vim_den_ganzen_Text_a_vim_terminal_murder_mystery_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/emf/2026/h264-hd/emf2026-29001-Endocrine_Biohacking_2_years_on_Everything_is_on_Fire_Edition_hd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/mrmcd/mrmcd26/h264-sd/mrmcd26-779-deu-Wie_die_ePA_so_die_Wallet_-_Eine_freundliche_Einfuehrung_in_unterkomplexe_IT-Infrastrukturen_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-416-eng-KDE_Linux_Under_the_Hood_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-387-eng-Making_NoNewPrivs_the_default_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-417-eng-Delivering_the_OS_via_OCI_images_Btrfs_snapshots_delta_updates_and_3-way_merges_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-399-eng-Running_mutable_OS_images_on_Confidential_VMs_is_there_any_hope_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-392-eng-Hold_My_Beer_Im_Building_100_Images_at_Once_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-425-eng-Kmod_-_teaching_old_dog_new_tricks_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-430-eng-Seamless_Upgrades_with_KHO_LUO_and_systemd_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-408-eng-Ten_Years_Building_Container_Networking_Lessons_Learned_and_What_the_Future_Might_Look_Like_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-431-eng-Modernising_Software_Distribution_with_Quarry_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-401-eng-OSPool_and_thin_volumes_Storage_for_Image-based_systems_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-393-eng-systemd_reducing_impact_of_servicing_interruptions_on_restart_reboot_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-437-eng-Varlink_observability_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-440-eng-binfmt_bpf_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-402-eng-Building_IncusOS_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-397-eng-Native_OS_enrollment_for_the_Linux_userspace_A_proposal_for_open_APIs_and_protocols_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-405-eng-Disk_encryption_using_attestation_for_Confidential_VMs_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-433-eng-An_API_for_systemd_Machines_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-423-eng-Building_image-based_operating_system_images_with_BuildStream_and_mkosi_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-441-eng-Managing_the_new_mount_api_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-435-eng-systemd_OCI_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-389-eng-systemd_state_of_the_project_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-445-eng-ParticleOS_in_action_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-447-eng-zbus_60_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-448-eng-systemd_services_as_microvms_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-390-eng-systemd_round_table_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-37-deu-Lightning_talk_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-46-eng-How_to_build_a_Corsi-Rosenthal_box_fan_filter_in_Europe_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-50-deu-Reisebericht_Zwischen_RAG_und_Real_Life_-_Lokale_KI_im_Praxiseinsatz_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-54-deu-Closing_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-49-eng-pyinfra_basics_-_you_dont_need_ansible_in_your_life_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-53-deu-Opening_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-35-deu-Android_internals_Ein_Einblick_ins_Innenleben_von_Android_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-47-deu-Druckerzeugnisse_mit_HTML_und_Print_CSS_erstellen_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/contributors/koeln/open_chaos/2026/h264-sd/openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110750-eng-Keynote_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110758-deu-Public_Money_Public_Containers_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/dgna/h264-hd/import-110771-deu-Automatisiertes_Fahren_Von_der_Science-Fiction_in_die_Realitaet_hd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-11-eng-What_Has_Been_Brewing_in_KDE_PIM_Land_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-618-deu-SKAfD_-_Trompetenpunk_aus_Dresden_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-646-eng-TiXim_-_a_decentralized_supercluster_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-608-deu-Mit_einem_demokratischen_digitalen_Euro_aus_der_Polykrise_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-36-eng-License_all_the_files_o_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-2-eng-How_to_cut_a_tree_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-14-eng-StyleKit_-_A_common_QML_API_for_styling_Controls_and_Widgets_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-15-eng-Dolphin_the_beloved_filemanager_past_and_future_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-59-eng-Sponsors_talks_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-735-deu-Aber_hier_Leben_Nein_danke_oder_doch_Wie_wir_der_autoritaeren_Zuspitzung_begegnen_koennen_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-733-deu-Russische_Drohnen_zerlegen_fuer_Anfaenger_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-712-deu-Closing_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-637-deu-Wir_haben_unser_Leben_heruntergeladen_Was_Unternehmen_wirklich_ueber_uns_wissen_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-41-eng-Report_of_the_board_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-689-deu-Build_Europes_Fediverse_Video_Infrastructure_-_Aufbau_1_europaeischen_Fediverse-Videoinfrastruktur_sd.mp4"/>
        <rdf:li resource="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4"/>
      </rdf:Seq>
    </items>
  </channel>
  <image rdf:about="/images/frontend/feed-banner.png">
    <title>Chaos Computer Club - last 100 events feed</title>
    <url>/images/frontend/feed-banner.png</url>
    <link>//media.ccc.de/</link>
  </image>
  <item rdf:about="https://cdn.media.ccc.de/contributors/noname_ev/h264-sd/import-110780-deu-Warum_loescht_ue_in_vim_den_ganzen_Text_a_vim_terminal_murder_mystery_sd.mp4">
    <title>Warum löscht ü in vim den ganzen Text? a vim/terminal murder mystery (noname_ev)</title>
    <link>https://cdn.media.ccc.de/contributors/noname_ev/h264-sd/import-110780-deu-Warum_loescht_ue_in_vim_den_ganzen_Text_a_vim_terminal_murder_mystery_sd.mp4</link>
    <description>Wenn man auf einer englischen Mac-Tastatur versucht, in vim im insert-Modus ein ü einzugeben, dann verschwindet der eingegebene Text. Warum ist das so und was kann man dagegen tun?

Wie tief geht der Kaninchenbau? Wir fangen bei einer Tastatur an und Enden im vim source code. Ein Krimi in N Teilen.

Links und Quellen:
    - Vortrag auf der Vereinsseite: https://www.noname-ev.de/chaotische_viertelstunde.html#c14h_690
    - Mac Keyboard, Apple Inc., https://www.apple.com/shop/product/mxcl3ll/a/magic-keyboard-usb-c-us-english?fnode=9db455efa598aae11d7d6d4bc9115563bc90f3a09097f5ea0a3f9cf6c22580ffa9cbe0b7076f414ee04e059d0e27e3534caa7b8a7339177ad3e19a0d8f940f17e6ef6fc43622b1a4f2bc4585b6c1c240d42f061cddc9ab5b254c7eaa51e268fe282a15cda094c9fa83389608adca493f
    - Space Cadet Keyboard (Symbolics LM-2 Lisp machine space-cadet keyboard), Shieldforyoureyes Dave Fischer / Retro-Computing Society of Rhode Island, Creative Commons Attribution-Share Alike 3.0 Unported https://creativecommons.org/licenses/by-sa/3.0/deed.en: https://en.wikipedia.org/wiki/File:Space-cadet.jpg
    - ASCII Table: https://en.wikipedia.org/wiki/ASCII
    - Alt Key: https://en.wikipedia.org/wiki/Alt_key
    - Option Key: https://en.wikipedia.org/wiki/Option_key
    - Meta Key: https://en.wikipedia.org/wiki/Meta_key
    - Kitty Keyboard Protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
    - Latin-1: https://en.wikipedia.org/wiki/ISO/IEC_8859-1
    - Vim Source Code: https://github.com/vim/vim/blob/master/
about this event: https://www.noname-ev.de/chaotische_viertelstunde.html#c14h_690
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Wenn man auf einer englischen Mac-Tastatur versucht, in vim im insert-Modus ein ü einzugeben, dann verschwindet der eingegebene Text. Warum ist das so und was kann man dagegen tun?

Wie tief geht der Kaninchenbau? Wir fangen bei einer Tastatur an und Enden im vim source code. Ein Krimi in N Teilen.

Links und Quellen:
    - Vortrag auf der Vereinsseite: https://www.noname-ev.de/chaotische_viertelstunde.html#c14h_690
    - Mac Keyboard, Apple Inc., https://www.apple.com/shop/product/mxcl3ll/a/magic-keyboard-usb-c-us-english?fnode=9db455efa598aae11d7d6d4bc9115563bc90f3a09097f5ea0a3f9cf6c22580ffa9cbe0b7076f414ee04e059d0e27e3534caa7b8a7339177ad3e19a0d8f940f17e6ef6fc43622b1a4f2bc4585b6c1c240d42f061cddc9ab5b254c7eaa51e268fe282a15cda094c9fa83389608adca493f
    - Space Cadet Keyboard (Symbolics LM-2 Lisp machine space-cadet keyboard), Shieldforyoureyes Dave Fischer / Retro-Computing Society of Rhode Island, Creative Commons Attribution-Share Alike 3.0 Unported https://creativecommons.org/licenses/by-sa/3.0/deed.en: https://en.wikipedia.org/wiki/File:Space-cadet.jpg
    - ASCII Table: https://en.wikipedia.org/wiki/ASCII
    - Alt Key: https://en.wikipedia.org/wiki/Alt_key
    - Option Key: https://en.wikipedia.org/wiki/Option_key
    - Meta Key: https://en.wikipedia.org/wiki/Meta_key
    - Kitty Keyboard Protocol: https://sw.kovidgoyal.net/kitty/keyboard-protocol/
    - Latin-1: https://en.wikipedia.org/wiki/ISO/IEC_8859-1
    - Vim Source Code: https://github.com/vim/vim/blob/master/
about this event: https://www.noname-ev.de/chaotische_viertelstunde.html#c14h_690
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/noname_ev-110780-warum-loscht-u-in-vim-d&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/contributors/noname_ev/110780-37c944fa-bfe3-49d4-a982-150d5ba5a877.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/contributors/noname_ev/h264-sd/import-110780-deu-Warum_loescht_ue_in_vim_den_ganzen_Text_a_vim_terminal_murder_mystery_sd.mp4&quot;&gt;import-110780-deu-Warum_loescht_ue_in_vim_den_ganzen_Text_a_vim_terminal_murder_mystery_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-08-13T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/emf/2026/h264-hd/emf2026-29001-Endocrine_Biohacking_2_years_on_Everything_is_on_Fire_Edition_hd.mp4">
    <title>Endocrine Biohacking, 2 years on (Everything is on Fire Edition) (emf2026)</title>
    <link>https://cdn.media.ccc.de/events/emf/2026/h264-hd/emf2026-29001-Endocrine_Biohacking_2_years_on_Everything_is_on_Fire_Edition_hd.mp4</link>
    <description>With the NHS promising to &quot;review&quot; care for transgender adults, community science and manufacturing capabilities are stepping up where healthcare has failed for decades.

Come be part of that community, make your own HRT.

It&#39;s cheap, safe, and lifesaving medical care when there&#39;s no-one left to turn to but ourselves!

Learn:
Why biohacking is cool, and still a human right no matter what governments may want,
How to manage your endocrine care, and help others stay informed,
How to move from buying pre-made meds, to safely making your own, and
Risk modelling updated for dangerous times.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://www.emfcamp.org/schedule/2026/290-endocrine-biohacking
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      With the NHS promising to &quot;review&quot; care for transgender adults, community science and manufacturing capabilities are stepping up where healthcare has failed for decades.

Come be part of that community, make your own HRT.

It&#39;s cheap, safe, and lifesaving medical care when there&#39;s no-one left to turn to but ourselves!

Learn:
Why biohacking is cool, and still a human right no matter what governments may want,
How to manage your endocrine care, and help others stay informed,
How to move from buying pre-made meds, to safely making your own, and
Risk modelling updated for dangerous times.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://www.emfcamp.org/schedule/2026/290-endocrine-biohacking
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/emf2026-290-1-endocrine-biohacking&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/emf/2026/29001-dbe23fbc-0eb5-5a30-8f75-b124b7a3be5c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/emf/2026/h264-hd/emf2026-29001-Endocrine_Biohacking_2_years_on_Everything_is_on_Fire_Edition_hd.mp4&quot;&gt;emf2026-29001-Endocrine_Biohacking_2_years_on_Everything_is_on_Fire_Edition_hd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-07-19T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/mrmcd/mrmcd26/h264-sd/mrmcd26-779-deu-Wie_die_ePA_so_die_Wallet_-_Eine_freundliche_Einfuehrung_in_unterkomplexe_IT-Infrastrukturen_sd.mp4">
    <title>Wie die ePA so die Wallet - Eine freundliche Einführung in unterkomplexe IT-Infrastrukturen (mrmcd26)</title>
    <link>https://cdn.media.ccc.de/events/mrmcd/mrmcd26/h264-sd/mrmcd26-779-deu-Wie_die_ePA_so_die_Wallet_-_Eine_freundliche_Einfuehrung_in_unterkomplexe_IT-Infrastrukturen_sd.mp4</link>
    <description>Wie auf dem 39. Chaos Communication Congress (39C3) von Bianca Kastl dargelegt, gab es bereits im Dezember 2025 umfassende Parallelen zwischen der EU-DI-Wallet und der elektronischen Patientenakte (ePA). Dieser Trend hat sich im Laufe des Jahres 2026 fortgesetzt. Es wird gezeigt was die ePA und die EU-DI-Wallet mit Sproks gemeinsam haben. Was die politischen Fragen bei digitalen Identitäten sind, zum Abschluss gibt es ein paar Faktenchecks.

Bei der Umsetzung öffentlicher digitaler Infrastrukturen wird bei der Umsetzung der gesetzlichen Vorgaben der technische Lösungsraum nicht vollständig ausgeschöpft.

Infrastrukturlösungen wie die ePA und die EU-DI-Wallet bilden die Grundlage für skalierbare Multi-Party-Multi-User Infrastrukturen. 

In der politischen Debatte wird jedoch häufig die Komplexität der technischen Lösung mit der Komplexität der Nutzung gleichgesetzt.

Anstatt nach lege artis modulare Architekturen mit gestuften Sicherheitsprozessen aufzubauen, wird versucht, mit einer One-Size-Fits-All-Lösung zu arbeiten. Aus Edge-Cases resultieren gegenläufige technischen Anforderungen, bei dem Versuch diese in Einklang zu bringen, fallen Datenschutz und IT-Sicherheit als &quot;nicht funktionale Features&quot; hinten runter.

Auch Best Practices aus dem Bereich Security by UX, die sich beispielsweise durch die PSD2-Richtlinie  beim kontaktlosen Bezahlen etabliert haben (etwa das Vorhalten des Handys, das Einstecken der Karte oder die PIN-Eingabe), bleiben unberücksichtigt. Das Ergebnis sind unterkomplexe Lösungen. 

Für Nutzer:innen ergibt sich daraus zum einen, dass das User Experience (UX) und User Interface (UI) aufgrund des One-Size-Fits-All-Ansatzes hinter kommerziellen Lösungen die sie im Alltag erleben zurückbleiben. Die Tatsache, dass staatliche Großprojekte wie die ePA sich keine Sorgen um Kongress Ticket machen müssen – es gibt jedes Jahr einen kritischen Vortrag  – schadet dem Vertrauen der Bevölkerung in die Lösungen und damit letztlich in die staatliche Handlungsfähigkeit.

Die obigen Thesen werden anhand der Fallbeispiele ePA und EU-DI-Wallet diskutiert.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://talks.mrmcd.net/2026/talk/C8SR8D/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Wie auf dem 39. Chaos Communication Congress (39C3) von Bianca Kastl dargelegt, gab es bereits im Dezember 2025 umfassende Parallelen zwischen der EU-DI-Wallet und der elektronischen Patientenakte (ePA). Dieser Trend hat sich im Laufe des Jahres 2026 fortgesetzt. Es wird gezeigt was die ePA und die EU-DI-Wallet mit Sproks gemeinsam haben. Was die politischen Fragen bei digitalen Identitäten sind, zum Abschluss gibt es ein paar Faktenchecks.

Bei der Umsetzung öffentlicher digitaler Infrastrukturen wird bei der Umsetzung der gesetzlichen Vorgaben der technische Lösungsraum nicht vollständig ausgeschöpft.

Infrastrukturlösungen wie die ePA und die EU-DI-Wallet bilden die Grundlage für skalierbare Multi-Party-Multi-User Infrastrukturen. 

In der politischen Debatte wird jedoch häufig die Komplexität der technischen Lösung mit der Komplexität der Nutzung gleichgesetzt.

Anstatt nach lege artis modulare Architekturen mit gestuften Sicherheitsprozessen aufzubauen, wird versucht, mit einer One-Size-Fits-All-Lösung zu arbeiten. Aus Edge-Cases resultieren gegenläufige technischen Anforderungen, bei dem Versuch diese in Einklang zu bringen, fallen Datenschutz und IT-Sicherheit als &quot;nicht funktionale Features&quot; hinten runter.

Auch Best Practices aus dem Bereich Security by UX, die sich beispielsweise durch die PSD2-Richtlinie  beim kontaktlosen Bezahlen etabliert haben (etwa das Vorhalten des Handys, das Einstecken der Karte oder die PIN-Eingabe), bleiben unberücksichtigt. Das Ergebnis sind unterkomplexe Lösungen. 

Für Nutzer:innen ergibt sich daraus zum einen, dass das User Experience (UX) und User Interface (UI) aufgrund des One-Size-Fits-All-Ansatzes hinter kommerziellen Lösungen die sie im Alltag erleben zurückbleiben. Die Tatsache, dass staatliche Großprojekte wie die ePA sich keine Sorgen um Kongress Ticket machen müssen – es gibt jedes Jahr einen kritischen Vortrag  – schadet dem Vertrauen der Bevölkerung in die Lösungen und damit letztlich in die staatliche Handlungsfähigkeit.

Die obigen Thesen werden anhand der Fallbeispiele ePA und EU-DI-Wallet diskutiert.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://talks.mrmcd.net/2026/talk/C8SR8D/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/2026-779-wie-die-epa-so-die-wallet-eine-freundliche-einfuhrung-in-unterkomplexe-it-infrastrukturen&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/mrmcd/mrmcd26/779-9ad259ce-ccc0-5322-b92e-6e939bfcca35.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/mrmcd/mrmcd26/h264-sd/mrmcd26-779-deu-Wie_die_ePA_so_die_Wallet_-_Eine_freundliche_Einfuehrung_in_unterkomplexe_IT-Infrastrukturen_sd.mp4&quot;&gt;mrmcd26-779-deu-Wie_die_ePA_so_die_Wallet_-_Eine_freundliche_Einfuehrung_in_unterkomplexe_IT-Infrastrukturen_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-12T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-416-eng-KDE_Linux_Under_the_Hood_sd.mp4">
    <title>KDE Linux Under the Hood (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-416-eng-KDE_Linux_Under_the_Hood_sd.mp4</link>
    <description>KDE&#39;s new image-based Linux distribution embraces modern technologies whenever possible. We&#39;ll explore all the tools that contribute, and how they are being utilized to form the final product. From building the disk image to eventually updating it on the user&#39;s system.

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/VXGVJF/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      KDE&#39;s new image-based Linux distribution embraces modern technologies whenever possible. We&#39;ll explore all the tools that contribute, and how they are being utilized to form the final product. From building the disk image to eventually updating it on the user&#39;s system.

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/VXGVJF/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-416-kde-linux-under-the-hood&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/416-52ca4659-77eb-5657-8401-71035bd4dd5e.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-416-eng-KDE_Linux_Under_the_Hood_sd.mp4&quot;&gt;asg2026-416-eng-KDE_Linux_Under_the_Hood_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-387-eng-Making_NoNewPrivs_the_default_sd.mp4">
    <title>Making NoNewPrivs the default (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-387-eng-Making_NoNewPrivs_the_default_sd.mp4</link>
    <description>This talk will give an update on make NoNewPrivs the default on a Linux distribution.

Running systems with “NoNewPrivs” by default is already possible  without issues for many use cases, but there are still some cases where it doesn&#39;t work. As followup to last year&#39;s presentation “Accessing shadow records via varlink” this session provides an up-to-date status report on the progress made and the issues that remain.

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/CG9K7H/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      This talk will give an update on make NoNewPrivs the default on a Linux distribution.

Running systems with “NoNewPrivs” by default is already possible  without issues for many use cases, but there are still some cases where it doesn&#39;t work. As followup to last year&#39;s presentation “Accessing shadow records via varlink” this session provides an up-to-date status report on the progress made and the issues that remain.

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/CG9K7H/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-387-making-nonewprivs-the-default&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/387-d20f427d-86c5-55cf-8c4b-31e1db728976.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-387-eng-Making_NoNewPrivs_the_default_sd.mp4&quot;&gt;asg2026-387-eng-Making_NoNewPrivs_the_default_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-417-eng-Delivering_the_OS_via_OCI_images_Btrfs_snapshots_delta_updates_and_3-way_merges_sd.mp4">
    <title>Delivering the OS via OCI images: Btrfs snapshots, delta updates and 3-way merges (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-417-eng-Delivering_the_OS_via_OCI_images_Btrfs_snapshots_delta_updates_and_3-way_merges_sd.mp4</link>
    <description>Delivering a Linux OS via OCI images unifies infrastructure management but often introduces severe network and state-reconciliation bottlenecks. This talk dives into the mechanics of solving these challenges by applying OS updates directly from OCI images to btrfs snapshots. We will explore how to drastically optimize these atomic upgrades using zstd-chunked compression, enabling systems to execute file-level delta updates via HTTP range requests instead of pulling full layers. Finally, we will demonstrate how to leverage snapper for seamless 3-way merges, safely reconciling upstream OS changes with local user configurations.

The transition to image-based, immutable Linux systems fundamentally changes OS management, but it also introduces complex network and storage challenges that are often abstracted away. This session explores the architecture and technical workflows required to provision and upgrade an OS using OCI images, advanced compression, and copy-on-write filesystems.
The foundation of this approach relies on mapping OCI images directly to btrfs snapshots. OCI image layers are pulled, unpacked, and directly applied as immutable btrfs snapshots, forming the read-only root volume of the system while maintaining distinct writable areas for persistent state.
To eliminate the network bottleneck of pulling full OCI layers for minor patches, we will detail efficient delta updates with zstd-chunked OCI images. The OS agent identifies and downloads only the specific files that have changed between the current running image and the target image. We will explain the mechanics of using HTTP range requests to extract these payloads and write them directly into the target btrfs snapshot on the fly, drastically reducing update times and bandwidth consumption without requiring full local extraction.
Finally, an immutable OS still requires localized configuration (e.g., in /etc), creating a challenge when the base OS image is updated. We will explore how to solve this using a 3-way merge strategy. In particular we will see how snapper is utilized to navigate btrfs snapshot trees and isolate the precise differences between the original base image, the user&#39;s localized state, and the incoming update. Having a clear picture of the differences in multiple directions allows us to define an algorithmic approach to safely merging these three states.

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/E7L8GD/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Delivering a Linux OS via OCI images unifies infrastructure management but often introduces severe network and state-reconciliation bottlenecks. This talk dives into the mechanics of solving these challenges by applying OS updates directly from OCI images to btrfs snapshots. We will explore how to drastically optimize these atomic upgrades using zstd-chunked compression, enabling systems to execute file-level delta updates via HTTP range requests instead of pulling full layers. Finally, we will demonstrate how to leverage snapper for seamless 3-way merges, safely reconciling upstream OS changes with local user configurations.

The transition to image-based, immutable Linux systems fundamentally changes OS management, but it also introduces complex network and storage challenges that are often abstracted away. This session explores the architecture and technical workflows required to provision and upgrade an OS using OCI images, advanced compression, and copy-on-write filesystems.
The foundation of this approach relies on mapping OCI images directly to btrfs snapshots. OCI image layers are pulled, unpacked, and directly applied as immutable btrfs snapshots, forming the read-only root volume of the system while maintaining distinct writable areas for persistent state.
To eliminate the network bottleneck of pulling full OCI layers for minor patches, we will detail efficient delta updates with zstd-chunked OCI images. The OS agent identifies and downloads only the specific files that have changed between the current running image and the target image. We will explain the mechanics of using HTTP range requests to extract these payloads and write them directly into the target btrfs snapshot on the fly, drastically reducing update times and bandwidth consumption without requiring full local extraction.
Finally, an immutable OS still requires localized configuration (e.g., in /etc), creating a challenge when the base OS image is updated. We will explore how to solve this using a 3-way merge strategy. In particular we will see how snapper is utilized to navigate btrfs snapshot trees and isolate the precise differences between the original base image, the user&#39;s localized state, and the incoming update. Having a clear picture of the differences in multiple directions allows us to define an algorithmic approach to safely merging these three states.

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/E7L8GD/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-417-delivering-the-os-via-oci-images-btrfs-snapshots-delta-updates-and-3-way-merges&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/417-7c1d8289-f0dc-5fb6-be8e-534ec1ba9c32.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-417-eng-Delivering_the_OS_via_OCI_images_Btrfs_snapshots_delta_updates_and_3-way_merges_sd.mp4&quot;&gt;asg2026-417-eng-Delivering_the_OS_via_OCI_images_Btrfs_snapshots_delta_updates_and_3-way_merges_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-399-eng-Running_mutable_OS_images_on_Confidential_VMs_is_there_any_hope_sd.mp4">
    <title>Running mutable OS images on Confidential VMs: is there any hope? (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-399-eng-Running_mutable_OS_images_on_Confidential_VMs_is_there_any_hope_sd.mp4</link>
    <description>Confidential VM (CVM) instance types are becoming ubiquitous, with all major cloud providers offering them as a key component for achieving “zero trust.” While complete zero trust is currently more of a marketing term than a technical reality, we can acknowledge that CVM technologies help reduce the Trusted Computing Base (TCB) when utilized properly. But do we actually know how to use them effectively?
When transitioning from a world of traditional, mutable operating systems, users often expect to gain security benefits simply by moving their existing workloads to new CVM instance types, perhaps with some level of attestation. Unfortunately, in many cases, this looks more like a role play in a “security theater”.
Over the past few years, we have investigated what security benefits can truly be unlocked when mutable RHEL or Fedora workloads are deployed on confidential VMs, whether in the public cloud or on-premises. While immutable OSes offer distinct advantages in such scenarios, we pose the question: can traditional (mutable) OSes also benefit? Over the last year, we have contributed several features to systemd (and other components) that we believe can improve the situation. In particular, we are focused on preventing certain attack scenarios against a VM which is normally deployed from a publicly available cloud (marketplace) image. We have further ideas, and in this talk, we will share our vision for how these pieces can fit together.

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/VNXPQS/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Confidential VM (CVM) instance types are becoming ubiquitous, with all major cloud providers offering them as a key component for achieving “zero trust.” While complete zero trust is currently more of a marketing term than a technical reality, we can acknowledge that CVM technologies help reduce the Trusted Computing Base (TCB) when utilized properly. But do we actually know how to use them effectively?
When transitioning from a world of traditional, mutable operating systems, users often expect to gain security benefits simply by moving their existing workloads to new CVM instance types, perhaps with some level of attestation. Unfortunately, in many cases, this looks more like a role play in a “security theater”.
Over the past few years, we have investigated what security benefits can truly be unlocked when mutable RHEL or Fedora workloads are deployed on confidential VMs, whether in the public cloud or on-premises. While immutable OSes offer distinct advantages in such scenarios, we pose the question: can traditional (mutable) OSes also benefit? Over the last year, we have contributed several features to systemd (and other components) that we believe can improve the situation. In particular, we are focused on preventing certain attack scenarios against a VM which is normally deployed from a publicly available cloud (marketplace) image. We have further ideas, and in this talk, we will share our vision for how these pieces can fit together.

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/VNXPQS/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-399-running-mutable-os-images-on-confidential-vms-is-there-any-hope-&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/399-454959b1-8c6b-53d8-8388-a9069e9d6901.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-399-eng-Running_mutable_OS_images_on_Confidential_VMs_is_there_any_hope_sd.mp4&quot;&gt;asg2026-399-eng-Running_mutable_OS_images_on_Confidential_VMs_is_there_any_hope_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-392-eng-Hold_My_Beer_Im_Building_100_Images_at_Once_sd.mp4">
    <title>Hold My Beer, I&#39;m Building 100 Images at Once (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-392-eng-Hold_My_Beer_Im_Building_100_Images_at_Once_sd.mp4</link>
    <description>In this talk, we&#39;ll walk through the architecture of Amutable&#39;s OS image build system. We&#39;ll dive into how we mirror rpms from Fedora and orchestrate building those rpms from source, as well as building OS images with buck2, an open source monorepo build system.

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/YSR3PP/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this talk, we&#39;ll walk through the architecture of Amutable&#39;s OS image build system. We&#39;ll dive into how we mirror rpms from Fedora and orchestrate building those rpms from source, as well as building OS images with buck2, an open source monorepo build system.

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/YSR3PP/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-392-hold-my-beer-i-m-building-100-images-at-once&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/392-37703396-54c9-5dcd-978c-ac48c8ffb14b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-392-eng-Hold_My_Beer_Im_Building_100_Images_at_Once_sd.mp4&quot;&gt;asg2026-392-eng-Hold_My_Beer_Im_Building_100_Images_at_Once_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-425-eng-Kmod_-_teaching_old_dog_new_tricks_sd.mp4">
    <title>Kmod — teaching old dog new tricks (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-425-eng-Kmod_-_teaching_old_dog_new_tricks_sd.mp4</link>
    <description>In this talk we&#39;ll cover the developments in kmod over the past few years. We&#39;ll wiz past the documentation and contribution updates, outline some of the performance improvements and discuss  the latest APIs introduced.

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/TTFUPB/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this talk we&#39;ll cover the developments in kmod over the past few years. We&#39;ll wiz past the documentation and contribution updates, outline some of the performance improvements and discuss  the latest APIs introduced.

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/TTFUPB/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-425-kmod-teaching-old-dog-new-tricks&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/425-f46235f5-6342-5549-8eda-019adbbb43b7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-425-eng-Kmod_-_teaching_old_dog_new_tricks_sd.mp4&quot;&gt;asg2026-425-eng-Kmod_-_teaching_old_dog_new_tricks_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-430-eng-Seamless_Upgrades_with_KHO_LUO_and_systemd_sd.mp4">
    <title>Seamless Upgrades with KHO, LUO, and systemd (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-430-eng-Seamless_Upgrades_with_KHO_LUO_and_systemd_sd.mp4</link>
    <description>For years, kexec was the standard way to skip lengthy firmware and bootloader delays at reboot. However, in modern cloud environments, even a fast reboot causes severe service degradation. Guests evacuation in virtualized environments or rebuild of massive in-memory caches for large databases is costly and disruptive.

Kernel HandOver (KHO) and Live Update Orchestrator (LUO) introduce a complete framework for seamless kernel and userspace state preservation across upgrades.

KHO provides the infrastructure to preserve kernel data structures and arbitrary memory regions across kexec. Physically contiguous memory areas managed by KHO let the incoming kernel to bootstrap itself without touching the preserved memory.

On top of KHO, LUO provides userspace APIs for coordination of the transition and allows applications to preserve file descriptors across kexec. With initial support for memory file descriptors (memfd), the ecosystem is rapidly expanding to cover subsystems like PCI, VFIO, KVM, guestmemfd, and iommufd.

Moreover, the ecosystem now features native systemd integration, leveraging the standard fdstore interface to pass resources across the kernel 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/J8GNND/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      For years, kexec was the standard way to skip lengthy firmware and bootloader delays at reboot. However, in modern cloud environments, even a fast reboot causes severe service degradation. Guests evacuation in virtualized environments or rebuild of massive in-memory caches for large databases is costly and disruptive.

Kernel HandOver (KHO) and Live Update Orchestrator (LUO) introduce a complete framework for seamless kernel and userspace state preservation across upgrades.

KHO provides the infrastructure to preserve kernel data structures and arbitrary memory regions across kexec. Physically contiguous memory areas managed by KHO let the incoming kernel to bootstrap itself without touching the preserved memory.

On top of KHO, LUO provides userspace APIs for coordination of the transition and allows applications to preserve file descriptors across kexec. With initial support for memory file descriptors (memfd), the ecosystem is rapidly expanding to cover subsystems like PCI, VFIO, KVM, guestmemfd, and iommufd.

Moreover, the ecosystem now features native systemd integration, leveraging the standard fdstore interface to pass resources across the kernel 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/J8GNND/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-430-seamless-upgrades-with-kho-luo-and-systemd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/430-b23e7390-95a8-5c6e-bc93-35864b84b95c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-430-eng-Seamless_Upgrades_with_KHO_LUO_and_systemd_sd.mp4&quot;&gt;asg2026-430-eng-Seamless_Upgrades_with_KHO_LUO_and_systemd_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-408-eng-Ten_Years_Building_Container_Networking_Lessons_Learned_and_What_the_Future_Might_Look_Like_sd.mp4">
    <title>Ten Years Building Container Networking: Lessons Learned and What the Future Might Look Like (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-408-eng-Ten_Years_Building_Container_Networking_Lessons_Learned_and_What_the_Future_Might_Look_Like_sd.mp4</link>
    <description>A decade ago, container networking was in its infancy, relying heavily on complex bridges and iptables rules. Today, the landscape has fundamentally shifted towards highly performant, secure, and observable dataplanes powered by eBPF.  
  
In this talk, a core contributor to Cilium reflects on a decade of building container networking solutions - from the early days of Weave Net to modern eBPF-based architectures. We will explore the hard-fought engineering lessons from migrating away from traditional kernel bottlenecks and discuss how Cilium evolved into the most widely used container networking plugin (CNI) and a foundational platform for advanced networking research. Finally, we will look to the horizon to discuss what the next decade of Linux system networking holds.

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/R7BEEK/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      A decade ago, container networking was in its infancy, relying heavily on complex bridges and iptables rules. Today, the landscape has fundamentally shifted towards highly performant, secure, and observable dataplanes powered by eBPF.  
  
In this talk, a core contributor to Cilium reflects on a decade of building container networking solutions - from the early days of Weave Net to modern eBPF-based architectures. We will explore the hard-fought engineering lessons from migrating away from traditional kernel bottlenecks and discuss how Cilium evolved into the most widely used container networking plugin (CNI) and a foundational platform for advanced networking research. Finally, we will look to the horizon to discuss what the next decade of Linux system networking holds.

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/R7BEEK/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-408-ten-years-building-container-networking-lessons-learned-and-what-the-future-might-look-like&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/408-9f1ef3fb-d209-550c-afe1-1a7c468b85de.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-408-eng-Ten_Years_Building_Container_Networking_Lessons_Learned_and_What_the_Future_Might_Look_Like_sd.mp4&quot;&gt;asg2026-408-eng-Ten_Years_Building_Container_Networking_Lessons_Learned_and_What_the_Future_Might_Look_Like_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-431-eng-Modernising_Software_Distribution_with_Quarry_sd.mp4">
    <title>Modernising Software Distribution with Quarry (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-431-eng-Modernising_Software_Distribution_with_Quarry_sd.mp4</link>
    <description>`systemd-sysupdate` provides a lot of incredibly useful primitives for doing system updates, but it is still mostly designed around old-school `SHA256SUMS` distribution and static transfer definitions.

The need to have more autonomous systems for updating systems and adding components became quite clear when we started developing such systems at Amutable. This approach also dove-tailed nicely into developing an autonomous provisioning system using the same underlying mechanism, [leading us to build Quarry](https://amutable.com/blog/distributing-images-quarry) (which has been [recently open sourced](https://github.com/amutable-systems/quarry)).

This talk will contain a discussion of the architecture we came up with, the pain points with integration with `systemd-sysupdate`, as well as some of the caveats that such an architecture has with generic distributions.

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/BBJYFH/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      `systemd-sysupdate` provides a lot of incredibly useful primitives for doing system updates, but it is still mostly designed around old-school `SHA256SUMS` distribution and static transfer definitions.

The need to have more autonomous systems for updating systems and adding components became quite clear when we started developing such systems at Amutable. This approach also dove-tailed nicely into developing an autonomous provisioning system using the same underlying mechanism, [leading us to build Quarry](https://amutable.com/blog/distributing-images-quarry) (which has been [recently open sourced](https://github.com/amutable-systems/quarry)).

This talk will contain a discussion of the architecture we came up with, the pain points with integration with `systemd-sysupdate`, as well as some of the caveats that such an architecture has with generic distributions.

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/BBJYFH/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-431-modernising-software-distribution-with-quarry&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/431-7feb9e3e-54ce-5075-ba0a-b9ed7a94cbcd.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-431-eng-Modernising_Software_Distribution_with_Quarry_sd.mp4&quot;&gt;asg2026-431-eng-Modernising_Software_Distribution_with_Quarry_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-401-eng-OSPool_and_thin_volumes_Storage_for_Image-based_systems_sd.mp4">
    <title>OSPool and thin volumes: Storage for Image-based systems (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-401-eng-OSPool_and_thin_volumes_Storage_for_Image-based_systems_sd.mp4</link>
    <description>Image-based Linux systems have different storage requirements from traditional mutable systems as they rely on signed, immutable disk images for software delivery and separate writable filesystems for data.

Technologies like systemd-homed require that multiple writable filesystems share the same backing storage. This thin provisioning is not something that is well supported by Linux today as filesystems are not aware of it. Another area for improvement is that many disk images often contain similar data that could be deduplicated.

We will present a storage system prototype designed for the usecases of image based systems and our plans for improving thin provisioning on Linux.

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/WSNAQL/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Image-based Linux systems have different storage requirements from traditional mutable systems as they rely on signed, immutable disk images for software delivery and separate writable filesystems for data.

Technologies like systemd-homed require that multiple writable filesystems share the same backing storage. This thin provisioning is not something that is well supported by Linux today as filesystems are not aware of it. Another area for improvement is that many disk images often contain similar data that could be deduplicated.

We will present a storage system prototype designed for the usecases of image based systems and our plans for improving thin provisioning on Linux.

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/WSNAQL/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-401-ospool-and-thin-volumes-storage-for-image-based-systems&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/401-454fd98a-35e5-5b72-8887-5750a414cda7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-401-eng-OSPool_and_thin_volumes_Storage_for_Image-based_systems_sd.mp4&quot;&gt;asg2026-401-eng-OSPool_and_thin_volumes_Storage_for_Image-based_systems_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-393-eng-systemd_reducing_impact_of_servicing_interruptions_on_restart_reboot_sd.mp4">
    <title>systemd: reducing impact of servicing interruptions on restart/reboot (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-393-eng-systemd_reducing_impact_of_servicing_interruptions_on_restart_reboot_sd.mp4</link>
    <description>When a machine/server/node is serviced and experiences a downtime, that results in a service interruption, customers or users tend to get quite sad. This talk will explore two recent additions to systemd that aim to make these service interruptions as minimal as possible.

systemd v260 and v261 added two features which aim to let service owners minimize downtime.

Firstly, when services use dm-verity images, profiling data showed that the largest bottleneck by far was loading the new images, which used to happen after the running service had already stopped during a unit restart. Since v260, when very specific conditions are met, this bottleneck has been removed from the critical path.

Secondly, a common issue causing slowdowns for services is having to serialize and deserialize large amount of state from slow disks after a reboot due to an OS update. Since v261, systemd supports the kernel&#39;s Live Update Orchestration, and uses it to persist the content of the FD Store across a kexec reboot. Services can use a memfd for their runtime state, hand it over the systemd when they are stopped/restarted, and they will get it back and can mmap it and use it straight away on restart. With LUO support, services can rely on this even across a kexec, removing the need to use serialize and deserialize state to disk.

This talk will explore both features, explaining how they work and how they can be used.

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/XFZKN8/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      When a machine/server/node is serviced and experiences a downtime, that results in a service interruption, customers or users tend to get quite sad. This talk will explore two recent additions to systemd that aim to make these service interruptions as minimal as possible.

systemd v260 and v261 added two features which aim to let service owners minimize downtime.

Firstly, when services use dm-verity images, profiling data showed that the largest bottleneck by far was loading the new images, which used to happen after the running service had already stopped during a unit restart. Since v260, when very specific conditions are met, this bottleneck has been removed from the critical path.

Secondly, a common issue causing slowdowns for services is having to serialize and deserialize large amount of state from slow disks after a reboot due to an OS update. Since v261, systemd supports the kernel&#39;s Live Update Orchestration, and uses it to persist the content of the FD Store across a kexec reboot. Services can use a memfd for their runtime state, hand it over the systemd when they are stopped/restarted, and they will get it back and can mmap it and use it straight away on restart. With LUO support, services can rely on this even across a kexec, removing the need to use serialize and deserialize state to disk.

This talk will explore both features, explaining how they work and how they can be used.

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/XFZKN8/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-393-systemd-reducing-impact-of-servicing-interruptions-on-restart-reboot&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/393-295fed84-a14f-5608-940e-0b28d5fd1b85.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-393-eng-systemd_reducing_impact_of_servicing_interruptions_on_restart_reboot_sd.mp4&quot;&gt;asg2026-393-eng-systemd_reducing_impact_of_servicing_interruptions_on_restart_reboot_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-437-eng-Varlink_observability_sd.mp4">
    <title>Varlink observability (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-437-eng-Varlink_observability_sd.mp4</link>
    <description>Varlink is slowly getting adopted in the desktop space. This brings a few new challenges, one of them being observability: D-Bus allows us to capture the entire system and session bus and then drill down on specific interactions in the system. Varlink on the other hand is just a protocol spoken over AF_UNIX sockets and thus has no bus and no global view of the system. The talk explores how we can use eBPF and extended attributes on sockets to give us back the observability we&#39;re used to with D-Bus.

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/FKWEC8/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Varlink is slowly getting adopted in the desktop space. This brings a few new challenges, one of them being observability: D-Bus allows us to capture the entire system and session bus and then drill down on specific interactions in the system. Varlink on the other hand is just a protocol spoken over AF_UNIX sockets and thus has no bus and no global view of the system. The talk explores how we can use eBPF and extended attributes on sockets to give us back the observability we&#39;re used to with D-Bus.

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/FKWEC8/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-437-varlink-observability&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/437-3e14be2b-6d9e-5e3b-9969-64f867c05a8b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-437-eng-Varlink_observability_sd.mp4&quot;&gt;asg2026-437-eng-Varlink_observability_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-440-eng-binfmt_bpf_sd.mp4">
    <title>binfmt_bpf (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-440-eng-binfmt_bpf_sd.mp4</link>
    <description>In this talk we will look at how binfmt and bpf can be integrated.

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/8SCGQC/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this talk we will look at how binfmt and bpf can be integrated.

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/8SCGQC/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-440-binfmtbpf&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/440-485cf1f0-2be1-5d8a-ae8d-5c409337b8b4.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-440-eng-binfmt_bpf_sd.mp4&quot;&gt;asg2026-440-eng-binfmt_bpf_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-402-eng-Building_IncusOS_sd.mp4">
    <title>Building IncusOS (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-402-eng-Building_IncusOS_sd.mp4</link>
    <description>[IncusOS](https://linuxcontainers.org/incus-os) is an immutable OS based on Debian 13 and built using mkosi. It&#39;s designed to be as secure as possible, actively relying on both UEFI Secure Boot and a TPM 2.0 module to provide strong boot security as well as encryption at rest through LUKS+TPM.

Its whole purpose is to provide an ideal environment for running [Incus](https://linuxcontainers.org/incus/) with a focus on running on bare metal with pretty complex local and remote storage as well as a variety of networking options.

Unlike most other Linux systems, IncusOS doesn&#39;t provide any local or remote shell access to the system. Instead it&#39;s entirely API driven with its management API being available through the Incus API itself.

That management API allows for system configuration, update management, installation of additional components (systemd system extensions), configuring a variety of system services, ... But it also needs to handle a variety of fallback and recovery/patching mechanisms for when something goes wrong.

This talk will cover why we built IncusOS, how we built it, its current state and what we&#39;re working towards in the near future.

[Incus](https://linuxcontainers.org/incus/) is a modern container and virtual machine manager with native support for both system and application containers as well as virtual machines. It&#39;s designed to behave just like a private cloud, but one that you can run on your laptop or Raspberry Pi as well as on clusters of hundreds or thousands of servers.

It&#39;s got support for a wide variety of local and remote storage options as well as both software defined and traditional networking. It has built-in clustering allowing for hundreds of servers to act as one with a consistent API and distributed database providing high availability and automated recovery.

Incus is widely available through packages in most Linux distributions with IncusOS providing another method of deployment particularly targeted to those who don&#39;t want to have to manage yet another Linux system or those who want to perform large scale deployments with known identical systems.

IncusOS can be deployed and managed at scale through [Operations Center](https://github.com/futurfusion/operations-center), allowing for hundreds of clusters to be deployed, updated and tracked in one place.

Incus, IncusOS, Operations Center and generally everything related to Incus is Open Source and released under the Apache 2.0 license.

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/ER3SSR/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      [IncusOS](https://linuxcontainers.org/incus-os) is an immutable OS based on Debian 13 and built using mkosi. It&#39;s designed to be as secure as possible, actively relying on both UEFI Secure Boot and a TPM 2.0 module to provide strong boot security as well as encryption at rest through LUKS+TPM.

Its whole purpose is to provide an ideal environment for running [Incus](https://linuxcontainers.org/incus/) with a focus on running on bare metal with pretty complex local and remote storage as well as a variety of networking options.

Unlike most other Linux systems, IncusOS doesn&#39;t provide any local or remote shell access to the system. Instead it&#39;s entirely API driven with its management API being available through the Incus API itself.

That management API allows for system configuration, update management, installation of additional components (systemd system extensions), configuring a variety of system services, ... But it also needs to handle a variety of fallback and recovery/patching mechanisms for when something goes wrong.

This talk will cover why we built IncusOS, how we built it, its current state and what we&#39;re working towards in the near future.

[Incus](https://linuxcontainers.org/incus/) is a modern container and virtual machine manager with native support for both system and application containers as well as virtual machines. It&#39;s designed to behave just like a private cloud, but one that you can run on your laptop or Raspberry Pi as well as on clusters of hundreds or thousands of servers.

It&#39;s got support for a wide variety of local and remote storage options as well as both software defined and traditional networking. It has built-in clustering allowing for hundreds of servers to act as one with a consistent API and distributed database providing high availability and automated recovery.

Incus is widely available through packages in most Linux distributions with IncusOS providing another method of deployment particularly targeted to those who don&#39;t want to have to manage yet another Linux system or those who want to perform large scale deployments with known identical systems.

IncusOS can be deployed and managed at scale through [Operations Center](https://github.com/futurfusion/operations-center), allowing for hundreds of clusters to be deployed, updated and tracked in one place.

Incus, IncusOS, Operations Center and generally everything related to Incus is Open Source and released under the Apache 2.0 license.

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/ER3SSR/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-402-building-incusos&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/402-8d949343-0bd6-527f-9773-99eab8f9dbb9.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-402-eng-Building_IncusOS_sd.mp4&quot;&gt;asg2026-402-eng-Building_IncusOS_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-397-eng-Native_OS_enrollment_for_the_Linux_userspace_A_proposal_for_open_APIs_and_protocols_sd.mp4">
    <title>Native OS enrollment for the Linux userspace: A proposal for open APIs and protocols (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-397-eng-Native_OS_enrollment_for_the_Linux_userspace_A_proposal_for_open_APIs_and_protocols_sd.mp4</link>
    <description>Enterprise Linux deployments lack a standardized, native enrollment flow. Current solutions rely on distro‑specific first‑boot mechanisms (systemd-firstboot, cloud‑init, realmd, ignition, kickstart and more) or external configuration management layered post‑deployment, resulting in poor feature sets w.r.t. modern features enabled by TPM2 or UEFI setting management.

This talk proposes to explore minimal, vendor‑neutral set of APIs and protocols for OS enrollment, *analogous to* Windows Autopilot but designed for the Linux userspace stack and specifically for the ParticleOS ecosystem. We will examine a concrete model based on device identity (TPM, SMBIOS information), secure attestation, policy discovery, and management‑hint delivery, decoupled from any particular configuration management system.

There might be a live demonstration presenting a reference implementation on NixOS communicating with a lightweight enrollment service over HTTP(S) leveraging a bunch of Varlink APIs built across the past years and presented at ASG.

The primary outcome is a community‑reviewed specification draft for enrollment APIs, intended for integration into systemd and distro installers.

The talk is not a proposal for a new tool but rather invite the attendees to think about the problem space around corporate enrollment for Linux distributions and how do we build native solutions for distributions interested by this idea.

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/3RTJNA/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Enterprise Linux deployments lack a standardized, native enrollment flow. Current solutions rely on distro‑specific first‑boot mechanisms (systemd-firstboot, cloud‑init, realmd, ignition, kickstart and more) or external configuration management layered post‑deployment, resulting in poor feature sets w.r.t. modern features enabled by TPM2 or UEFI setting management.

This talk proposes to explore minimal, vendor‑neutral set of APIs and protocols for OS enrollment, *analogous to* Windows Autopilot but designed for the Linux userspace stack and specifically for the ParticleOS ecosystem. We will examine a concrete model based on device identity (TPM, SMBIOS information), secure attestation, policy discovery, and management‑hint delivery, decoupled from any particular configuration management system.

There might be a live demonstration presenting a reference implementation on NixOS communicating with a lightweight enrollment service over HTTP(S) leveraging a bunch of Varlink APIs built across the past years and presented at ASG.

The primary outcome is a community‑reviewed specification draft for enrollment APIs, intended for integration into systemd and distro installers.

The talk is not a proposal for a new tool but rather invite the attendees to think about the problem space around corporate enrollment for Linux distributions and how do we build native solutions for distributions interested by this idea.

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/3RTJNA/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-397-native-os-enrollment-for-the-linux-userspace-a-proposal-for-open-apis-and-protocols&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/397-27dafc2c-48af-55ef-ad16-a46c90e776e0.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-397-eng-Native_OS_enrollment_for_the_Linux_userspace_A_proposal_for_open_APIs_and_protocols_sd.mp4&quot;&gt;asg2026-397-eng-Native_OS_enrollment_for_the_Linux_userspace_A_proposal_for_open_APIs_and_protocols_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-405-eng-Disk_encryption_using_attestation_for_Confidential_VMs_sd.mp4">
    <title>Disk encryption using attestation for Confidential VMs (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-405-eng-Disk_encryption_using_attestation_for_Confidential_VMs_sd.mp4</link>
    <description>When a VM is confidential (CVM), the host cannot access its memory, enabling data-in-use protection. Hardware vendors like Intel (TDX) and AMD (SEV-SNP) provide the underlying technology to achieve this. The use case becomes more complex when a persistent disk is added to a CVM: the disk must also be encrypted, but how can we safely manage its encryption keys without trusting the host? We propose a mechanism to encrypt and decrypt a disk using remote attestation: the passphrase is stored in a Key Broker Service (KBS) that only releases it when the identity of the VM is verified. During the first boot, systemd-repart encrypts the root disk using a random key that is generated and stored in KBS. On subsequent boots, systemd-cryptsetup requests the same key to decrypt the disk. We present the changes we are working on to support this use case in components like KubeVirt, Trustee, and systemd-repart. We present PRs for Trustee, systemd-repart, and KubeVirt, along with a new LUKS token plugin that integrates systemd-repart and systemd-cryptsetup with KBS for key retrieval. This use case extends beyond KubeVirt and applies to any environment where confidential workloads require encrypted persistent storage, including bare metal deployments.

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/TKKLMZ/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      When a VM is confidential (CVM), the host cannot access its memory, enabling data-in-use protection. Hardware vendors like Intel (TDX) and AMD (SEV-SNP) provide the underlying technology to achieve this. The use case becomes more complex when a persistent disk is added to a CVM: the disk must also be encrypted, but how can we safely manage its encryption keys without trusting the host? We propose a mechanism to encrypt and decrypt a disk using remote attestation: the passphrase is stored in a Key Broker Service (KBS) that only releases it when the identity of the VM is verified. During the first boot, systemd-repart encrypts the root disk using a random key that is generated and stored in KBS. On subsequent boots, systemd-cryptsetup requests the same key to decrypt the disk. We present the changes we are working on to support this use case in components like KubeVirt, Trustee, and systemd-repart. We present PRs for Trustee, systemd-repart, and KubeVirt, along with a new LUKS token plugin that integrates systemd-repart and systemd-cryptsetup with KBS for key retrieval. This use case extends beyond KubeVirt and applies to any environment where confidential workloads require encrypted persistent storage, including bare metal deployments.

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/TKKLMZ/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-405-disk-encryption-using-attestation-for-confidential-vms&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/405-6c328e0c-1963-5f7a-9cec-6736acad9cf7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-405-eng-Disk_encryption_using_attestation_for_Confidential_VMs_sd.mp4&quot;&gt;asg2026-405-eng-Disk_encryption_using_attestation_for_Confidential_VMs_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-433-eng-An_API_for_systemd_Machines_sd.mp4">
    <title>An API for systemd Machines (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-433-eng-An_API_for_systemd_Machines_sd.mp4</link>
    <description>In this talk I&#39;d like to provide a vision for accessing systemd hosts via local IPC APIs and remote RPC APIs. With the Varlinkification of systemd going full steam ahead, I&#39;d like to explain what I think should be next for systemd and how things fit together with our focus on APIs.

We&#39;ll talk about metrics/reports, Varlink in general, the Varlink HTTP proxy specifically, about security models, and zero-agent remote access, secure system parameterization and more. We&#39;ll talk about design patterns to follow, both for systemd components, and for other OS components, outside of it.

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/RZ3PUB/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this talk I&#39;d like to provide a vision for accessing systemd hosts via local IPC APIs and remote RPC APIs. With the Varlinkification of systemd going full steam ahead, I&#39;d like to explain what I think should be next for systemd and how things fit together with our focus on APIs.

We&#39;ll talk about metrics/reports, Varlink in general, the Varlink HTTP proxy specifically, about security models, and zero-agent remote access, secure system parameterization and more. We&#39;ll talk about design patterns to follow, both for systemd components, and for other OS components, outside of it.

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/RZ3PUB/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-433-an-api-for-systemd-machines&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/433-2f14c798-d2de-51aa-82df-284ad3c3dcc8.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-433-eng-An_API_for_systemd_Machines_sd.mp4&quot;&gt;asg2026-433-eng-An_API_for_systemd_Machines_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-423-eng-Building_image-based_operating_system_images_with_BuildStream_and_mkosi_sd.mp4">
    <title>Building image-based operating system images with BuildStream and mkosi (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-423-eng-Building_image-based_operating_system_images_with_BuildStream_and_mkosi_sd.mp4</link>
    <description>BuildStream is a tool for building / integrating software stacks. In a way, it has a similar goal to bitbake / yocto and Android&#39;s repo, but takes a completely different approach. It can be used to take software from various sources, build it with various buildsystems in a reproducible sandbox, and cache results for speedy rebuilds.

mkosi is a tool for easily building customized OS images. It is generally used with distros that have a package manager such as dnf or apt. There is however recent development to add support for using it with BuildStream.

In this talk I give a brief overview of Buildstream, and freedesktop-sdk which is a BuildStream project that can be used as a base to build your own operating system. While BuildStream on its own can build the whole thing, there are some advantages to using mkosi which I&#39;ll go over in this talk.

I&#39;ll also go over the challenges faced moving GNOME OS to use mkosi for generating the image.

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/DUNFF9/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      BuildStream is a tool for building / integrating software stacks. In a way, it has a similar goal to bitbake / yocto and Android&#39;s repo, but takes a completely different approach. It can be used to take software from various sources, build it with various buildsystems in a reproducible sandbox, and cache results for speedy rebuilds.

mkosi is a tool for easily building customized OS images. It is generally used with distros that have a package manager such as dnf or apt. There is however recent development to add support for using it with BuildStream.

In this talk I give a brief overview of Buildstream, and freedesktop-sdk which is a BuildStream project that can be used as a base to build your own operating system. While BuildStream on its own can build the whole thing, there are some advantages to using mkosi which I&#39;ll go over in this talk.

I&#39;ll also go over the challenges faced moving GNOME OS to use mkosi for generating the image.

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/DUNFF9/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-423-building-image-based-operating-system-images-with-buildstream-and-mkosi&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/423-74362ca8-ad35-5eb5-a96e-8d3720a47c22.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-423-eng-Building_image-based_operating_system_images_with_BuildStream_and_mkosi_sd.mp4&quot;&gt;asg2026-423-eng-Building_image-based_operating_system_images_with_BuildStream_and_mkosi_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-441-eng-Managing_the_new_mount_api_sd.mp4">
    <title>Managing the new mount api (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-441-eng-Managing_the_new_mount_api_sd.mp4</link>
    <description>A fundamental aspect of an OS security policy is the ability to manage mounting. That includes filesystem mounts, remounts, bind-mounts, and property changes. Contrary to popular believe Linux exposes only barebones policy hooks. This is about to change.

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/J9TM7X/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      A fundamental aspect of an OS security policy is the ability to manage mounting. That includes filesystem mounts, remounts, bind-mounts, and property changes. Contrary to popular believe Linux exposes only barebones policy hooks. This is about to change.

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/J9TM7X/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-441-managing-the-new-mount-api&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/441-bc672c96-6fac-5fcd-9897-8e1f44344ee9.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-441-eng-Managing_the_new_mount_api_sd.mp4&quot;&gt;asg2026-441-eng-Managing_the_new_mount_api_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-10-01T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-435-eng-systemd_OCI_sd.mp4">
    <title>systemd &amp; OCI (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-435-eng-systemd_OCI_sd.mp4</link>
    <description>Recently systemd acquired functionality to download &amp; invoke OCI containers directly. In this talk I&#39;d like to explain where we are at with this, what we have, where the gaps are and where we are going, to make OCI containers a thing you can directly execute with systemd, without external tools.

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/BWWVCN/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Recently systemd acquired functionality to download &amp; invoke OCI containers directly. In this talk I&#39;d like to explain where we are at with this, what we have, where the gaps are and where we are going, to make OCI containers a thing you can directly execute with systemd, without external tools.

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/BWWVCN/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-435-systemd-oci&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/435-2c2479f4-fccf-5076-a02c-77966ac8ba5b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-435-eng-systemd_OCI_sd.mp4&quot;&gt;asg2026-435-eng-systemd_OCI_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4">
    <title>attezt: device attestation, PKCS11 and ACME (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4</link>
    <description>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&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-414-attezt-device-attestation-pkcs11-and-acme&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/414-23d6c6b3-8a6b-5a07-8531-d9bab98c051b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4&quot;&gt;asg2026-414-eng-attezt_device_attestation_PKCS11_and_ACME_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-389-eng-systemd_state_of_the_project_sd.mp4">
    <title>systemd: state of the project (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-389-eng-systemd_state_of_the_project_sd.mp4</link>
    <description>Same as every year, a lot has happened in the systemd project since last year&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Same as every year, a lot has happened in the systemd project since last year&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-389-systemd-state-of-the-project&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/389-e8f38a6b-69e4-5d5e-82bb-9041d0331099.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-389-eng-systemd_state_of_the_project_sd.mp4&quot;&gt;asg2026-389-eng-systemd_state_of_the_project_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4">
    <title>Image Based Modular Deployment for Large Teams in Embedded Systems (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4</link>
    <description>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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-413-image-based-modular-deployment-for-large-teams-in-embedded-systems&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/413-9cbe8d11-14a1-5a9d-b7c9-a7e7a8723da2.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4&quot;&gt;asg2026-413-eng-Image_Based_Modular_Deployment_for_Large_Teams_in_Embedded_Systems_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4">
    <title>Forget &quot;podman generate systemd&quot;: How Quadlet Really Works (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4</link>
    <description>For a while, the standard way to run Podman containers under systemd was podman generate systemd. It worked, but the output was static and awkward to maintain. Quadlet replaced it — and most guides stop at &quot;drop an INI file in a directory and your container starts.&quot; leaving the machinery a black box. 

This talk demystifies that black box, because the internals are exactly what you reach for when things break. Quadlet isn&#39;t a daemon. It&#39;s a systemd generator that runs at daemon-reload and turns your .container, .pod, and .network files into ordinary .service units. 

In session, we&#39;ll trace one stack example from end to end, watching a three-line container file expand into a full podman run command, and cross-unit references become injected After=/Wants= dependency edges with name-mangled volumes and networks.

You&#39;ll leave knowing exactly what gets generated, why edits need a daemon-reload, how to dump &amp; debug a failing unit yourself, and explain why keeping only the source files under version control is reliable. Less magic, more model.

Quadlet isn&#39;t magic—it&#39;s a systemd generator. Watch a three-line .container file expand into a full service unit, and learn to dump, debug, and reason about what really gets generated.

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/PXBVLE/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      For a while, the standard way to run Podman containers under systemd was podman generate systemd. It worked, but the output was static and awkward to maintain. Quadlet replaced it — and most guides stop at &quot;drop an INI file in a directory and your container starts.&quot; leaving the machinery a black box. 

This talk demystifies that black box, because the internals are exactly what you reach for when things break. Quadlet isn&#39;t a daemon. It&#39;s a systemd generator that runs at daemon-reload and turns your .container, .pod, and .network files into ordinary .service units. 

In session, we&#39;ll trace one stack example from end to end, watching a three-line container file expand into a full podman run command, and cross-unit references become injected After=/Wants= dependency edges with name-mangled volumes and networks.

You&#39;ll leave knowing exactly what gets generated, why edits need a daemon-reload, how to dump &amp; debug a failing unit yourself, and explain why keeping only the source files under version control is reliable. Less magic, more model.

Quadlet isn&#39;t magic—it&#39;s a systemd generator. Watch a three-line .container file expand into a full service unit, and learn to dump, debug, and reason about what really gets generated.

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/PXBVLE/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-424-forget-podman-generate-systemd-how-quadlet-really-works&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/424-c073b66f-dd73-5f26-9374-9e026c064df7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4&quot;&gt;asg2026-424-eng-Forget_podman_generate_systemd_How_Quadlet_Really_Works_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-445-eng-ParticleOS_in_action_sd.mp4">
    <title>ParticleOS in action (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-445-eng-ParticleOS_in_action_sd.mp4</link>
    <description>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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-445-particleos-in-action&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/445-979df6f7-685d-5c80-9a2d-0370c9c6c180.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-445-eng-ParticleOS_in_action_sd.mp4&quot;&gt;asg2026-445-eng-ParticleOS_in_action_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4">
    <title>Provisioning and Deployment Mechanisms in systemd (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4</link>
    <description>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&#39;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&#39;d like to explain the current landscape, and how the various components matter in various scenarios, and how they fit together. I&#39;ll also discuss what&#39;s next, what&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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&#39;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&#39;d like to explain the current landscape, and how the various components matter in various scenarios, and how they fit together. I&#39;ll also discuss what&#39;s next, what&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-434-provisioning-and-deployment-mechanisms-in-systemd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/434-1838a8da-6c04-5fea-aedb-d86fbe7561ca.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4&quot;&gt;asg2026-434-eng-Provisioning_and_Deployment_Mechanisms_in_systemd_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4">
    <title>Couple Services, Not the Host: Portable Services and Capsules (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4</link>
    <description>System extensions (sysexts) become part of the host&#39;s /usr, making them available to all users. But what if we want to run tightly coupled services without exposing their binaries to everyone else on the system?

This lightning talk will show how to ship a real-world stack (kubelet, containerd, and runc) without making them accessible to the rest of the host. We will demonstrate how to use portable services and systemd capsules to allow these components to invoke each other and share some namespaces, all while keeping the host OS clean.

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/K9GPKV/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      System extensions (sysexts) become part of the host&#39;s /usr, making them available to all users. But what if we want to run tightly coupled services without exposing their binaries to everyone else on the system?

This lightning talk will show how to ship a real-world stack (kubelet, containerd, and runc) without making them accessible to the rest of the host. We will demonstrate how to use portable services and systemd capsules to allow these components to invoke each other and share some namespaces, all while keeping the host OS clean.

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/K9GPKV/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-436-couple-services-not-the-host-portable-services-and-capsules&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/436-02e60db7-20dc-5495-a643-10171d7f38f7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4&quot;&gt;asg2026-436-eng-Couple_Services_Not_the_Host_Portable_Services_and_Capsules_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4">
    <title>Containers without a new runtime: sdme on systemd-nspawn (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4</link>
    <description>sdme is a single static binary that boots systemd-nspawn containers using copy-on-write roots (overlayfs layers or btrfs snapshots), with OCI registry pulling and Kubernetes Pod YAML support. No daemon, no runtime dependency beyond the systemd you already run.

Why I built it. Every container runtime reinvents what systemd already does well: process supervision, logging, cgroups, service ordering, socket activation. sdme makes the opposite bet. systemd-nspawn already boots a full system in isolation; the kernel already gives it a cheap copy-on-write root, whether through overlayfs or a btrfs snapshot. Put a thin, daemonless CLI over the two and you get container workflows (clone, import, pull, run) without a new runtime to install or a daemon to keep alive. It began as a one-command clone of the running host, but the bet is bigger than that: lean on the init system instead of rebuilding it.

What you get. Proper machine-like containers: each one runs a full systemd init with journald, D-Bus, and systemctl, not a single foreground process. Each container is highly configurable through native systemd surfaces, with per-container resource limits, networking, and drop-in config. Clone your running host into a throwaway container in one command; run a Docker Hub image (nginx, redis, postgres) as a managed systemd service instead of a foreground process; deploy a multi-container pod from Kubernetes Pod YAML with health probes, secrets, and configmaps. A rootfs can also come from any distro, an OCI registry, a tarball, or a QCOW2 image, and you can build your own from a Dockerfile-like config.

How it works. One copy-on-write root and one systemd-nspawn invocation give you a fully booted system. Storage is pluggable per container. The overlayfs backend mounts the host / (or any imported rootfs) as an immutable lower layer with a fresh upper, so clones are instant. The btrfs backend snapshots the base rootfs as a subvolume instead, which makes the container root a real filesystem: nested containers work, user namespaces use native idmapped mounts, and per-container disk quotas come from qgroups. It runs directly on a btrfs data directory, or inside a loopback pool image on any other filesystem. The binary does two jobs: it manages those copy-on-write roots, and it drives systemd over D-Bus to start, stop, and supervise containers. Everything else (init, journald, cgroups, service ordering) is systemd doing what it already does, with no daemon in the middle.

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/E7MHZJ/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      sdme is a single static binary that boots systemd-nspawn containers using copy-on-write roots (overlayfs layers or btrfs snapshots), with OCI registry pulling and Kubernetes Pod YAML support. No daemon, no runtime dependency beyond the systemd you already run.

Why I built it. Every container runtime reinvents what systemd already does well: process supervision, logging, cgroups, service ordering, socket activation. sdme makes the opposite bet. systemd-nspawn already boots a full system in isolation; the kernel already gives it a cheap copy-on-write root, whether through overlayfs or a btrfs snapshot. Put a thin, daemonless CLI over the two and you get container workflows (clone, import, pull, run) without a new runtime to install or a daemon to keep alive. It began as a one-command clone of the running host, but the bet is bigger than that: lean on the init system instead of rebuilding it.

What you get. Proper machine-like containers: each one runs a full systemd init with journald, D-Bus, and systemctl, not a single foreground process. Each container is highly configurable through native systemd surfaces, with per-container resource limits, networking, and drop-in config. Clone your running host into a throwaway container in one command; run a Docker Hub image (nginx, redis, postgres) as a managed systemd service instead of a foreground process; deploy a multi-container pod from Kubernetes Pod YAML with health probes, secrets, and configmaps. A rootfs can also come from any distro, an OCI registry, a tarball, or a QCOW2 image, and you can build your own from a Dockerfile-like config.

How it works. One copy-on-write root and one systemd-nspawn invocation give you a fully booted system. Storage is pluggable per container. The overlayfs backend mounts the host / (or any imported rootfs) as an immutable lower layer with a fresh upper, so clones are instant. The btrfs backend snapshots the base rootfs as a subvolume instead, which makes the container root a real filesystem: nested containers work, user namespaces use native idmapped mounts, and per-container disk quotas come from qgroups. It runs directly on a btrfs data directory, or inside a loopback pool image on any other filesystem. The binary does two jobs: it manages those copy-on-write roots, and it drives systemd over D-Bus to start, stop, and supervise containers. Everything else (init, journald, cgroups, service ordering) is systemd doing what it already does, with no daemon in the middle.

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/E7MHZJ/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-403-containers-without-a-new-runtime-sdme-on-systemd-nspawn&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/403-e2f479b8-b1d0-55d7-a086-3b4b34b1aacf.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4&quot;&gt;asg2026-403-eng-Containers_without_a_new_runtime_sdme_on_systemd-nspawn_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4">
    <title>Proposal for TPM2+FIDO2 enrollment in systemd (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4</link>
    <description>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&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-394-proposal-for-tpm2-fido2-enrollment-in-systemd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/394-23b0213c-cfe6-5daf-a7f9-dd6bb7cafcec.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4&quot;&gt;asg2026-394-eng-Proposal_for_TPM2_FIDO2_enrollment_in_systemd_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4">
    <title>Modernizing local storage management for systemd services (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4</link>
    <description>The storage directory settings in systemd help define where services store their data. Two important features have been implemented for these directories. The first one is id-mapped mounts, which is a filesystem feature that allows a mount namespace to show a different UID than what is stored on a file. Storage directories now support id-mapping, so that the files within the mount namespace of a service defined with DynamicUser=yes are owned by its unprivileged UID/GID. The second feature is storage quota support. Storage limits can now be defined in terms of percentages or absolute values to enforce quotas on the consumption of State, Cache, and Logs directories. These features enhance the security and resource management of systemd services.

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/N93KWW/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      The storage directory settings in systemd help define where services store their data. Two important features have been implemented for these directories. The first one is id-mapped mounts, which is a filesystem feature that allows a mount namespace to show a different UID than what is stored on a file. Storage directories now support id-mapping, so that the files within the mount namespace of a service defined with DynamicUser=yes are owned by its unprivileged UID/GID. The second feature is storage quota support. Storage limits can now be defined in terms of percentages or absolute values to enforce quotas on the consumption of State, Cache, and Logs directories. These features enhance the security and resource management of systemd services.

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/N93KWW/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-410-modernizing-local-storage-management-for-systemd-services&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/410-210a35a1-0980-5b55-8723-c14847aa9682.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4&quot;&gt;asg2026-410-eng-Modernizing_local_storage_management_for_systemd_services_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4">
    <title>An update on systemd-sysext/confext (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4</link>
    <description>The limitations of systemd-sysext/confext from the early days are mostly gone nowadays. The loading of extension images from the initrd means that generic content will behave as expected without any workarounds. New settings help making live reconfiguration work better as well. We will see how declarative configuration management with systemd-sysext/confext from git can be done with an OpenTofu/Terraform module. For image-based Linux binding configuration together with a pinned OS version is now possible through bootctl link. OS builders can ship /etc files through a default confext image.

systemd-sysext/confext: https://www.freedesktop.org/software/systemd/man/devel/systemd-sysext.html
bootctl: https://www.freedesktop.org/software/systemd/man/devel/bootctl.html

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/RMC879/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      The limitations of systemd-sysext/confext from the early days are mostly gone nowadays. The loading of extension images from the initrd means that generic content will behave as expected without any workarounds. New settings help making live reconfiguration work better as well. We will see how declarative configuration management with systemd-sysext/confext from git can be done with an OpenTofu/Terraform module. For image-based Linux binding configuration together with a pinned OS version is now possible through bootctl link. OS builders can ship /etc files through a default confext image.

systemd-sysext/confext: https://www.freedesktop.org/software/systemd/man/devel/systemd-sysext.html
bootctl: https://www.freedesktop.org/software/systemd/man/devel/bootctl.html

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/RMC879/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-429-an-update-on-systemd-sysext-confext&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/429-77c7da84-07e0-5723-bd69-5154710d6da1.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4&quot;&gt;asg2026-429-eng-An_update_on_systemd-sysext_confext_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4">
    <title>Immutable, Fully-Confined Debian Server Images, Even on a Raspberry Pi 3 (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4</link>
    <description>Using mkosi and apparmor.d as building blocks, this talk presents a prototype minimal Debian server. The goal is not to provide yet another Linux distribution, but to explore how hard it is to build personalized, hardened server images.

On top of the usual mkosi-backed features such as UKIs, A/B updates and dm-verity, the project adds a whole-system AppArmor policy and an immutable `/etc`. Because older devices also matter, the prototype supports the Raspberry Pi 3 (UEFI) too, with minor changes to the security model. The talk presents the differences in design, attacker model, and implementation between the various targets.

This talk walks through a prototype: a minimal, hardened Debian server built with `mkosi` and `apparmor.d`. It composes three layers of systemd and Debian tooling that are well understood alone but rarely combined, each reinforcing the others:

- **Image-based OS:** `mkosi` magic.
- **Whole-system MAC:** AppArmor policies that confine every process on the system. It also brings:
    - Multi-layered policy loading, fixing the AppArmor load-time issues that hurt small devices.
    - Immutable security policies.
    - Compatibility with systemd sysext/confext.
- **Immutable `/etc`:** assembled from signed `systemd-confext` images, closing immutability&#39;s usual escape hatch.

The same image targets both an x86-64 server and a Raspberry Pi 3 (UEFI), and that contrast is where it gets interesting. The two share a single build but diverge on attacker model and security guarantees: what an embedded device with no Secure Boot can promise versus a server, and where the implementation has to bend. We walk those differences, the limitations, and what would have to land upstream to make this kind of image easier.

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/KJNYQ8/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Using mkosi and apparmor.d as building blocks, this talk presents a prototype minimal Debian server. The goal is not to provide yet another Linux distribution, but to explore how hard it is to build personalized, hardened server images.

On top of the usual mkosi-backed features such as UKIs, A/B updates and dm-verity, the project adds a whole-system AppArmor policy and an immutable `/etc`. Because older devices also matter, the prototype supports the Raspberry Pi 3 (UEFI) too, with minor changes to the security model. The talk presents the differences in design, attacker model, and implementation between the various targets.

This talk walks through a prototype: a minimal, hardened Debian server built with `mkosi` and `apparmor.d`. It composes three layers of systemd and Debian tooling that are well understood alone but rarely combined, each reinforcing the others:

- **Image-based OS:** `mkosi` magic.
- **Whole-system MAC:** AppArmor policies that confine every process on the system. It also brings:
    - Multi-layered policy loading, fixing the AppArmor load-time issues that hurt small devices.
    - Immutable security policies.
    - Compatibility with systemd sysext/confext.
- **Immutable `/etc`:** assembled from signed `systemd-confext` images, closing immutability&#39;s usual escape hatch.

The same image targets both an x86-64 server and a Raspberry Pi 3 (UEFI), and that contrast is where it gets interesting. The two share a single build but diverge on attacker model and security guarantees: what an embedded device with no Secure Boot can promise versus a server, and where the implementation has to bend. We walk those differences, the limitations, and what would have to land upstream to make this kind of image easier.

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/KJNYQ8/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-422-immutable-fully-confined-debian-server-images-even-on-a-raspberry-pi-3&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/422-08c82394-512b-595b-9361-b26698f3888e.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4&quot;&gt;asg2026-422-eng-Immutable_Fully-Confined_Debian_Server_Images_Even_on_a_Raspberry_Pi_3_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4">
    <title>single-file containers with statically linked systemd (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4</link>
    <description>Systemd can now be linked as a single static binary, which is enough to run a &quot;full system&quot; container that boots into a running manager. Transient units can then be used to do more things in the container. Thanks to systemd-nsresourced and systemd-mountfsd, this now works fully unprivileged and with no suid helpers. I want to show that this actually works and can be used for experimentation, development, and custom container images.

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/XU9CJR/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Systemd can now be linked as a single static binary, which is enough to run a &quot;full system&quot; container that boots into a running manager. Transient units can then be used to do more things in the container. Thanks to systemd-nsresourced and systemd-mountfsd, this now works fully unprivileged and with no suid helpers. I want to show that this actually works and can be used for experimentation, development, and custom container images.

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/XU9CJR/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-427-single-file-containers-with-statically-linked-systemd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/427-c0186a8b-1d94-53fe-989d-93ede50dc571.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4&quot;&gt;asg2026-427-eng-single-file_containers_with_statically_linked_systemd_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4">
    <title>From fsync to Block I/O: Tracing Storage with eBPF (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4</link>
    <description>Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don&#39;t tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue.

This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We&#39;ll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it.

Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can&#39;t see.

Follow a single write from syscall to block layer with eBPF, measuring honest per-layer latency at each handoff and attributing storage stalls to the service that caused them.

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/XHJX3N/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Observability stacks have gotten good at CPU, memory, and network — but storage is still where the picture goes dark. When a workload stalls on I/O, device-level tools like iostat or blktrace tell you the disk was busy; they don&#39;t tell you which service caused it, or where in the stack the latency actually accrued: a slow fsync, writeback pressure in the page cache, a filesystem journal commit, or a saturated block queue.

This talk follows a single write from the syscall boundary down to the block layer, using eBPF to instrument each handoff — VFS, the filesystem, the page cache, and block I/O submission and completion — without patching applications or running a custom kernel. We&#39;ll look at which attach points (tracepoints, fentry/fexit, kprobes) give honest per-layer latency, how to keep the measurement overhead from biasing the result, and how to attribute the latency back to the responsible cgroup or systemd service instead of an aggregate line on a dashboard. Examples range from fsync-heavy database commits to large sequential writes that look fine at the device level but stall well above it.

Attendees will leave with a concrete method for turning storage from a black box into a traceable path — and an honest sense of where eBPF helps, and where it still can&#39;t see.

Follow a single write from syscall to block layer with eBPF, measuring honest per-layer latency at each handoff and attributing storage stalls to the service that caused them.

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/XHJX3N/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-418-from-fsync-to-block-i-o-tracing-storage-with-ebpf&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/418-d672c0b5-5b41-59ed-9495-9e0ce89f5ec4.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4&quot;&gt;asg2026-418-eng-From_fsync_to_Block_I_O_Tracing_Storage_with_eBPF_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4">
    <title>Moonforge: Making Yocto Easy To Assemble (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4</link>
    <description>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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-409-moonforge-making-yocto-easy-to-assemble&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/409-6a8ae828-3791-5ceb-a655-b8bc6366533d.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4&quot;&gt;asg2026-409-eng-Moonforge_Making_Yocto_Easy_To_Assemble_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4">
    <title>Rethinking systemd-homed&#39;s Key Hierarchy (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4</link>
    <description>When you lock your systemd-homed enabled Linux desktop today, your home directory (including the desktop session) is fully frozen. This happens because systemd-homed uses a single cryptographic key (the LUKS volume key) and throws it away during lock. Want to lock away just your credentials as on a normal screen lock while keeping music playing and notifications coming through? You can&#39;t.

This talk presents the work done as part of the systemd STF grant to extend the systemd-homed&#39;s key hierarchy that fixes this issue.

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/TL3KGN/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      When you lock your systemd-homed enabled Linux desktop today, your home directory (including the desktop session) is fully frozen. This happens because systemd-homed uses a single cryptographic key (the LUKS volume key) and throws it away during lock. Want to lock away just your credentials as on a normal screen lock while keeping music playing and notifications coming through? You can&#39;t.

This talk presents the work done as part of the systemd STF grant to extend the systemd-homed&#39;s key hierarchy that fixes this issue.

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/TL3KGN/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-412-rethinking-systemd-homed-s-key-hierarchy&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/412-863d4702-cf23-5e03-942d-773cdc2ccbef.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4&quot;&gt;asg2026-412-eng-Rethinking_systemd-homeds_Key_Hierarchy_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4">
    <title>The state of systemd sandboxing in Debian (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4</link>
    <description>Marco will review the state of systemd sandboxing in Debian packages, what we need to fix to have more and what will break by enabling too much of it.

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/VLBXZ8/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Marco will review the state of systemd sandboxing in Debian packages, what we need to fix to have more and what will break by enabling too much of it.

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/VLBXZ8/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-400-the-state-of-systemd-sandboxing-in-debian&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/400-5aabf3ed-7f7c-5513-97ef-b7bef7371144.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4&quot;&gt;asg2026-400-eng-The_state_of_systemd_sandboxing_in_Debian_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4">
    <title>Measured Boot in NixOS &amp; Other systemd Updates (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4</link>
    <description>This talk will present the newest updates and advancements in NixOS related to Secure &amp; 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 -&gt; 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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      This talk will present the newest updates and advancements in NixOS related to Secure &amp; 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 -&gt; 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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-391-measured-boot-in-nixos-other-systemd-updates&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/391-f00ce030-06a4-5753-a902-837a0acc2aa6.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4&quot;&gt;asg2026-391-eng-Measured_Boot_in_NixOS_Other_systemd_Updates_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-447-eng-zbus_60_sd.mp4">
    <title>zbus 6.0 (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-447-eng-zbus_60_sd.mp4</link>
    <description>What&#39;s new in zbus

https://zeenix.github.io/presentations-marp/LTs/zbus-6-whats-new.html

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/3C8PUC/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      What&#39;s new in zbus

https://zeenix.github.io/presentations-marp/LTs/zbus-6-whats-new.html

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/3C8PUC/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-447-zbus-6-0&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/447-e42f3783-8315-5eb0-8b66-a587324a9f0a.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-447-eng-zbus_60_sd.mp4&quot;&gt;asg2026-447-eng-zbus_60_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4">
    <title>A unified OS installer in systemd (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4</link>
    <description>Linux doesn&#39;t have a unified way to be installed. Every distribution implements their own installer with a different feature set and UX. systemd-sysinstall is a tool to install an OS to a device. It leverages repart to format the disk and bootctl to manage UEFI and the boot partition and supports disk encryption and TPM integration. In addition, it exposes a varlink interface to be used by graphical installers.


In this talk we will explore what sysinstall does, how the GNOME OS installer (gnome-setup) leverages it to install GNOME OS, why distributions shipping GNOME should switch to gnome-setup, and how other desktop environments can build installers using the same stack.

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/SBUXXA/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Linux doesn&#39;t have a unified way to be installed. Every distribution implements their own installer with a different feature set and UX. systemd-sysinstall is a tool to install an OS to a device. It leverages repart to format the disk and bootctl to manage UEFI and the boot partition and supports disk encryption and TPM integration. In addition, it exposes a varlink interface to be used by graphical installers.


In this talk we will explore what sysinstall does, how the GNOME OS installer (gnome-setup) leverages it to install GNOME OS, why distributions shipping GNOME should switch to gnome-setup, and how other desktop environments can build installers using the same stack.

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/SBUXXA/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-404-a-unified-os-installer-in-systemd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/404-12e431be-561c-5a31-ab43-3529f43e232c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4&quot;&gt;asg2026-404-eng-A_unified_OS_installer_in_systemd_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-448-eng-systemd_services_as_microvms_sd.mp4">
    <title>systemd services as microvms (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-448-eng-systemd_services_as_microvms_sd.mp4</link>
    <description>What if we could run systemd services on top of virtual cpu/memory, to get hypervisor/cpu protection of memory pages? Demo of a very much work-in-progress proof-of-concept

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/7U77A3/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      What if we could run systemd services on top of virtual cpu/memory, to get hypervisor/cpu protection of memory pages? Demo of a very much work-in-progress proof-of-concept

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/7U77A3/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-448-systemd-services-as-microvms&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/448-5b74ae6e-b822-56c9-992a-6bbcc83c894d.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-448-eng-systemd_services_as_microvms_sd.mp4&quot;&gt;asg2026-448-eng-systemd_services_as_microvms_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4">
    <title>Do Users Actually Want a Trusted, Immutable OS?  Lessons from the Industry (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4</link>
    <description>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&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-395-do-users-actually-want-a-trusted-immutable-os-lessons-from-the-industry&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/395-c6f8d047-d6a3-5a25-9d87-6c1f487590bc.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4&quot;&gt;asg2026-395-eng-Do_Users_Actually_Want_a_Trusted_Immutable_OS_Lessons_from_the_Industry_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4">
    <title>Make Debian Immutable with mkosi and Nix (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4</link>
    <description>Immutable, image-based Linux has gone mainstream — on Fedora. Nearly every atomic distro descends from the RPM/ostree lineage. Debian is conspicuously rare, with really only Vanilla OS and Endless OS to its name. There&#39;s a reason, and it&#39;s apt: Debian&#39;s package manager expects a writable root filesystem, so the moment you seal the rootfs, the native way to install and update software stops working. That&#39;s the wall every immutable Debian hits, and most climb it with Flatpak or containers. This talk takes a different route — Nix. Nix keeps everything in a self-contained, content-addressed /nix/store, so it never needs a writable rootfs. The base is built once with mkosi and frozen (apt isn&#39;t even installed) and Nix manages everything that changes after that, reproducibly. The result is an immutable Debian rootfs with the entire Nix package ecosystem available on top.

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/BEDGKF/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Immutable, image-based Linux has gone mainstream — on Fedora. Nearly every atomic distro descends from the RPM/ostree lineage. Debian is conspicuously rare, with really only Vanilla OS and Endless OS to its name. There&#39;s a reason, and it&#39;s apt: Debian&#39;s package manager expects a writable root filesystem, so the moment you seal the rootfs, the native way to install and update software stops working. That&#39;s the wall every immutable Debian hits, and most climb it with Flatpak or containers. This talk takes a different route — Nix. Nix keeps everything in a self-contained, content-addressed /nix/store, so it never needs a writable rootfs. The base is built once with mkosi and frozen (apt isn&#39;t even installed) and Nix manages everything that changes after that, reproducibly. The result is an immutable Debian rootfs with the entire Nix package ecosystem available on top.

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/BEDGKF/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-415-make-debian-immutable-with-mkosi-and-nix&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/415-350cd483-8078-53e3-907c-6efc046537cb.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4&quot;&gt;asg2026-415-eng-Make_Debian_Immutable_with_mkosi_and_Nix_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-390-eng-systemd_round_table_sd.mp4">
    <title>systemd: round table (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-390-eng-systemd_round_table_sd.mp4</link>
    <description>Let&#39;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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Let&#39;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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-390-systemd-round-table&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/390-efb38d7d-3ebb-5e3e-8e8d-60a97940c534.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-390-eng-systemd_round_table_sd.mp4&quot;&gt;asg2026-390-eng-systemd_round_table_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4">
    <title>Bridging the (varlink) gap (asg2026)</title>
    <link>https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4</link>
    <description>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 &quot;more&quot; support or &quot;protocol-upgrade&quot; 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 &quot;just work&quot;. 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/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      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 &quot;more&quot; support or &quot;protocol-upgrade&quot; 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 &quot;just work&quot;. 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/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/all-systems-go-2026-407-bridging-the-varlink-gap&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/all_systems_go/2026/407-f859278b-e2af-5765-a085-756644211b26.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/all_systems_go/2026/h264-sd/asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4&quot;&gt;asg2026-407-eng-Bridging_the_varlink_gap_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-30T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-37-deu-Lightning_talk_sd.mp4">
    <title>Lightning talk (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-37-deu-Lightning_talk_sd.mp4</link>
    <description>Lightning talk slot, to present some lightning talks.

A slot for short talks about different topics, Can be in English or German.
Ein Programm Punkt in dem kurze Vorträge über verschiedene Themen vorgetragen werden können. Die Vorträge können in Deutsch oder Englisch gehalten werden.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/8AWG3G/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Lightning talk slot, to present some lightning talks.

A slot for short talks about different topics, Can be in English or German.
Ein Programm Punkt in dem kurze Vorträge über verschiedene Themen vorgetragen werden können. Die Vorträge können in Deutsch oder Englisch gehalten werden.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/8AWG3G/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-37-lightning-talk&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/37-41065ac1-294a-54ba-9cf0-c048a33bc944.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-37-deu-Lightning_talk_sd.mp4&quot;&gt;quellc0d3-37-deu-Lightning_talk_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-26T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-46-eng-How_to_build_a_Corsi-Rosenthal_box_fan_filter_in_Europe_sd.mp4">
    <title>How to build a Corsi-Rosenthal box fan filter... in Europe?? (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-46-eng-How_to_build_a_Corsi-Rosenthal_box_fan_filter_in_Europe_sd.mp4</link>
    <description>This talk is about how I built a Corsi-Rosenthal box fan filter without the resources used typically in the USA.

You probably have heard of them, maybe even saw them yourself: A box, with a bunch of air filters, and a fan on the top, all tied together with duct tape. It sucks air through the filters, and purified air comes out.

This DIY air purifier, as simple and cheap looking as it might be, turned out to be more effective than the more expensive ones from brands, and has made the lives of many better. The ongoing COVID pandemic, forest fires, SMOG... many situations where you want to have one in a room ( especially with several people inside! ).

You likely searched on Internet how to build one, and then come across detailed guides, telling you all what you need and the steps required.
But then there&#39;s a small detail that you soon catch: the components required are all from Costco or other American brands, which importation would render them anti-economical.

In this talk, I will share my experience of me building one up, coming up with alternatives that we can find at this side of the ocean.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/A3W7UN/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      This talk is about how I built a Corsi-Rosenthal box fan filter without the resources used typically in the USA.

You probably have heard of them, maybe even saw them yourself: A box, with a bunch of air filters, and a fan on the top, all tied together with duct tape. It sucks air through the filters, and purified air comes out.

This DIY air purifier, as simple and cheap looking as it might be, turned out to be more effective than the more expensive ones from brands, and has made the lives of many better. The ongoing COVID pandemic, forest fires, SMOG... many situations where you want to have one in a room ( especially with several people inside! ).

You likely searched on Internet how to build one, and then come across detailed guides, telling you all what you need and the steps required.
But then there&#39;s a small detail that you soon catch: the components required are all from Costco or other American brands, which importation would render them anti-economical.

In this talk, I will share my experience of me building one up, coming up with alternatives that we can find at this side of the ocean.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/A3W7UN/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-46-how-to-build-a-corsi-rosenthal-box-fan-filter-in-europe&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/46-84389f44-d494-5060-b37e-30154fc56a5c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-46-eng-How_to_build_a_Corsi-Rosenthal_box_fan_filter_in_Europe_sd.mp4&quot;&gt;quellc0d3-46-eng-How_to_build_a_Corsi-Rosenthal_box_fan_filter_in_Europe_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-27T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-50-deu-Reisebericht_Zwischen_RAG_und_Real_Life_-_Lokale_KI_im_Praxiseinsatz_sd.mp4">
    <title>„Reisebericht“: Zwischen RAG und Real Life – Lokale KI im Praxiseinsatz (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-50-deu-Reisebericht_Zwischen_RAG_und_Real_Life_-_Lokale_KI_im_Praxiseinsatz_sd.mp4</link>
    <description>Ich nehme euch mit auf meine (noch lange nicht abgeschlossene) Reise. Ich zeige euch meine Erfolge, meine (mitunter dummen) Fehler, echte Gamechanger und warum ich manchmal bewusst auf den Profi-Ansatz verzichtet habe. Und wie man im Dschungel aus 2,6 Millionen Modellen die Richtigen für den eigenen Zweck finden.

**Für Einsteiger und Technisch versierte Wesen:**
*Ich beginne den Vortrag mit einer kurzen Einführung in die Terminologie/Fachbegriffe, damit auch alle folgen können, die neu in der Tech-Bubble sind.*

Ich setze mich seit 2023 intensiv mit lokaler KI auseinander – also der Nutzung von Large Language Modellen (LLMs) ohne Internetverbindung und ohne Account bei den großen Anbietern (wie OpenAI oder Anthropic) auf dem eigenen Computer.

**Inhaltliche Schwerpunkte:**

* Was sind die generellen **Vor- und Nachteile** lokaler KI im Vergleich zu ChatGPT &amp; Co.?
* Wie lassen sich Modelle mit einem überschaubaren **Budget** lokal nutzen?
* Welche Anwendungsfälle ermöglichen einen **tatsächlichen Nutzen** im privaten und kleinst-gewerblichen Bereich?
* Wie mir LLMs helfen, Herausforderungen durch **Neurodivergenz** zu bewältigen.
* Häufige **Missconceptions** im Automatisierungsgame.
* **Evaluation** von LLMs (ohne vorher einen Doktortitel in Mathematik zu absolvieren).
* **Does it need AI?** Wie behalte ich Kosten-, Umwelt- und Datenschutzrisiken im Auge?
  


**Worum es NICHT geht:**

* Vergleich von Web-Diensten bzw. Closed Source / Proprietäre KI.
* Grafikkarten-Tipps.
* Die Mathematik hinter LLMs.
* Erstellung von Multimedia-Assets (Audio, Bild, Video) mit KI.
* Spekulative Diskussionen über AGI/philosophische-Bedrohungs-Szenarien.
* Juristische Analysen zu Urheberrechten.


**Tags:**
_[Lokale KI], [RAG], [LLM], [Datenschutz], [Souveränität], [Automatisierung], [Python],[n8n], [QDrant], [Embedding], [Superset], [Vektordatenbank], [Self-Hosting], [Produktivität], [Paperless-ngx], [Open Source], [Digitale Souveränität], [Neurodivergenz], [Evaluation]_

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/TWM7BH/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Ich nehme euch mit auf meine (noch lange nicht abgeschlossene) Reise. Ich zeige euch meine Erfolge, meine (mitunter dummen) Fehler, echte Gamechanger und warum ich manchmal bewusst auf den Profi-Ansatz verzichtet habe. Und wie man im Dschungel aus 2,6 Millionen Modellen die Richtigen für den eigenen Zweck finden.

**Für Einsteiger und Technisch versierte Wesen:**
*Ich beginne den Vortrag mit einer kurzen Einführung in die Terminologie/Fachbegriffe, damit auch alle folgen können, die neu in der Tech-Bubble sind.*

Ich setze mich seit 2023 intensiv mit lokaler KI auseinander – also der Nutzung von Large Language Modellen (LLMs) ohne Internetverbindung und ohne Account bei den großen Anbietern (wie OpenAI oder Anthropic) auf dem eigenen Computer.

**Inhaltliche Schwerpunkte:**

* Was sind die generellen **Vor- und Nachteile** lokaler KI im Vergleich zu ChatGPT &amp; Co.?
* Wie lassen sich Modelle mit einem überschaubaren **Budget** lokal nutzen?
* Welche Anwendungsfälle ermöglichen einen **tatsächlichen Nutzen** im privaten und kleinst-gewerblichen Bereich?
* Wie mir LLMs helfen, Herausforderungen durch **Neurodivergenz** zu bewältigen.
* Häufige **Missconceptions** im Automatisierungsgame.
* **Evaluation** von LLMs (ohne vorher einen Doktortitel in Mathematik zu absolvieren).
* **Does it need AI?** Wie behalte ich Kosten-, Umwelt- und Datenschutzrisiken im Auge?
  


**Worum es NICHT geht:**

* Vergleich von Web-Diensten bzw. Closed Source / Proprietäre KI.
* Grafikkarten-Tipps.
* Die Mathematik hinter LLMs.
* Erstellung von Multimedia-Assets (Audio, Bild, Video) mit KI.
* Spekulative Diskussionen über AGI/philosophische-Bedrohungs-Szenarien.
* Juristische Analysen zu Urheberrechten.


**Tags:**
_[Lokale KI], [RAG], [LLM], [Datenschutz], [Souveränität], [Automatisierung], [Python],[n8n], [QDrant], [Embedding], [Superset], [Vektordatenbank], [Self-Hosting], [Produktivität], [Paperless-ngx], [Open Source], [Digitale Souveränität], [Neurodivergenz], [Evaluation]_

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/TWM7BH/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-50-reisebericht-zwischen-rag-und-real-life-lokale-ki-im-praxiseinsatz&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/50-867255a7-a734-589a-8e99-ea5a244ae17b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-50-deu-Reisebericht_Zwischen_RAG_und_Real_Life_-_Lokale_KI_im_Praxiseinsatz_sd.mp4&quot;&gt;quellc0d3-50-deu-Reisebericht_Zwischen_RAG_und_Real_Life_-_Lokale_KI_im_Praxiseinsatz_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-26T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-54-deu-Closing_sd.mp4">
    <title>Closing (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-54-deu-Closing_sd.mp4</link>
    <description>Abschluss der Quellc0d3 bis zum nächsten Jahr

Wir werfen einen blick zurück auf die vergangenen tage, hoffentlich mit ein paar zahlen.
Geben euch einen kleinen einblick wie wir die Quellc0d3 auf die Beine gestellt haben

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/MFYKSS/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Abschluss der Quellc0d3 bis zum nächsten Jahr

Wir werfen einen blick zurück auf die vergangenen tage, hoffentlich mit ein paar zahlen.
Geben euch einen kleinen einblick wie wir die Quellc0d3 auf die Beine gestellt haben

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/MFYKSS/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-54-closing&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/54-89a089f7-6814-51c1-a3ed-5dcb45795068.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-54-deu-Closing_sd.mp4&quot;&gt;quellc0d3-54-deu-Closing_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-27T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-49-eng-pyinfra_basics_-_you_dont_need_ansible_in_your_life_sd.mp4">
    <title>pyinfra basics - you don&#39;t need ansible in your life (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-49-eng-pyinfra_basics_-_you_dont_need_ansible_in_your_life_sd.mp4</link>
    <description>Annoyed by ansible&#39;s yaml syntax? With pyinfra, you can write your declarative infrastructure config in python instead. With all the control flow logic, reusable libraries, and whole power of a turing-complete language you already know.

I can show you how we define our infrastructure in pyinfra, and some pyinfra libraries I wrote (for borgbackup, nginx, and wireguard). Then we can think together about the strengths and limitations of pyinfra, whether it would be useful for your projects, and how to migrate there.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/DYMNFL/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Annoyed by ansible&#39;s yaml syntax? With pyinfra, you can write your declarative infrastructure config in python instead. With all the control flow logic, reusable libraries, and whole power of a turing-complete language you already know.

I can show you how we define our infrastructure in pyinfra, and some pyinfra libraries I wrote (for borgbackup, nginx, and wireguard). Then we can think together about the strengths and limitations of pyinfra, whether it would be useful for your projects, and how to migrate there.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/DYMNFL/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-49-pyinfra-basics-you-don-t-need-ansible-in-your-life&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/49-38463ff8-5299-5f3f-b66c-2b73aeee1fba.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-49-eng-pyinfra_basics_-_you_dont_need_ansible_in_your_life_sd.mp4&quot;&gt;quellc0d3-49-eng-pyinfra_basics_-_you_dont_need_ansible_in_your_life_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-27T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4">
    <title>Who Owns Science? On Paywalls, Publishers, and paperstacks.io (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4</link>
    <description>Science depends on knowledge being shared, discovered, scrutinized, and built upon. Yet much of today’s scientific literature remains locked behind paywalls and is mediated by a handful of commercial publishers and platforms that increasingly control how research is accessed, organized, and made visible. In this talk, we examine how the current scholarly publishing ecosystem emerged, why it has become increasingly dependent on proprietary infrastructures, and what this means for science and society. We also introduce _paperstacks.io_, an open European infrastructure developed at Technische Hochschule Nürnberg for discovering, organizing, and sharing scientific knowledge.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/MAY8KV/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Science depends on knowledge being shared, discovered, scrutinized, and built upon. Yet much of today’s scientific literature remains locked behind paywalls and is mediated by a handful of commercial publishers and platforms that increasingly control how research is accessed, organized, and made visible. In this talk, we examine how the current scholarly publishing ecosystem emerged, why it has become increasingly dependent on proprietary infrastructures, and what this means for science and society. We also introduce _paperstacks.io_, an open European infrastructure developed at Technische Hochschule Nürnberg for discovering, organizing, and sharing scientific knowledge.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/MAY8KV/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-34-who-owns-science-on-paywalls-publishers-and-paperstacks-io&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/34-71b80a1e-a973-57ae-8a8c-b370aab663e6.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4&quot;&gt;quellc0d3-34-deu-Who_Owns_Science_On_Paywalls_Publishers_and_paperstacksio_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-25T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-53-deu-Opening_sd.mp4">
    <title>Opening (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-53-deu-Opening_sd.mp4</link>
    <description>Das offizielle Opening der Quellc0d3.

Wir werfen zu beging einen blick zurück auf das letztjährige Event und geben einen kurzen Überblick was euch die nächsten tage, erwartet.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/JJRZWS/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Das offizielle Opening der Quellc0d3.

Wir werfen zu beging einen blick zurück auf das letztjährige Event und geben einen kurzen Überblick was euch die nächsten tage, erwartet.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/JJRZWS/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-53-opening&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/53-baec8c47-667a-5133-b6ff-cc4f8cbaaa56.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-53-deu-Opening_sd.mp4&quot;&gt;quellc0d3-53-deu-Opening_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-25T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-35-deu-Android_internals_Ein_Einblick_ins_Innenleben_von_Android_sd.mp4">
    <title>Android internals. Ein Einblick ins Innenleben von Android (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-35-deu-Android_internals_Ein_Einblick_ins_Innenleben_von_Android_sd.mp4</link>
    <description>Google riegelt Android immer weiter ab. Aber da es Open Source ist, könnte man doch etwas machen. Allerdings versteht niemand Android. Deshalb ändern wir das!
Android OS Interna Einführung, für Menschen die sich mit Linux auskennen und/oder App Entwicklungserfahrung haben.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/TXMMBC/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Google riegelt Android immer weiter ab. Aber da es Open Source ist, könnte man doch etwas machen. Allerdings versteht niemand Android. Deshalb ändern wir das!
Android OS Interna Einführung, für Menschen die sich mit Linux auskennen und/oder App Entwicklungserfahrung haben.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/TXMMBC/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-35-android-internals-ein-einblick-ins-innenleben-von-android&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/35-57a9b965-1ddb-5b93-bf94-02a6083970e1.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-35-deu-Android_internals_Ein_Einblick_ins_Innenleben_von_Android_sd.mp4&quot;&gt;quellc0d3-35-deu-Android_internals_Ein_Einblick_ins_Innenleben_von_Android_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-26T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-47-deu-Druckerzeugnisse_mit_HTML_und_Print_CSS_erstellen_sd.mp4">
    <title>Druckerzeugnisse mit HTML und (Print) CSS erstellen (quellc0d3)</title>
    <link>https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-47-deu-Druckerzeugnisse_mit_HTML_und_Print_CSS_erstellen_sd.mp4</link>
    <description>HTML und CSS eignen sich gut, um Druckerzeugnisse (Flyer, Plakate, Bücher) zu designen. Vor allem wenn man die relevanten CSS Properties, Erweiterungen und Tools kennt. In diesem Vortrag stelle ich diese vor!

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/UXG3FF/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      HTML und CSS eignen sich gut, um Druckerzeugnisse (Flyer, Plakate, Bücher) zu designen. Vor allem wenn man die relevanten CSS Properties, Erweiterungen und Tools kennt. In diesem Vortrag stelle ich diese vor!

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://pretalx.0x90.space/quellcode-2026/talk/UXG3FF/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/quellcode-2026-47-druckerzeugnisse-mit-html-und-print-css-erstellen&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/conferences/quellcode/2026/47-63a2cfdd-01f1-559f-825c-f5c281ac1d09.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/quellcode/2026/h264-sd/quellc0d3-47-deu-Druckerzeugnisse_mit_HTML_und_Print_CSS_erstellen_sd.mp4&quot;&gt;quellc0d3-47-deu-Druckerzeugnisse_mit_HTML_und_Print_CSS_erstellen_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-26T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/contributors/koeln/open_chaos/2026/h264-sd/openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4">
    <title>Data Against Animal Experiments (oc)</title>
    <link>https://cdn.media.ccc.de/contributors/koeln/open_chaos/2026/h264-sd/openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4</link>
    <description>Building AI-Powered Databases to Overcome Outdated Practices and Advance Human-Based Research.

Doctors Against Animal Experiments (DAAE), an NGO based in Cologne, advocates for a phase-out of animal experiments and a shift towards ethical, human-based research. Alongside public outreach, campaigns, and political advocacy, DAAE develops and maintains four databases designed to accelerate this transition and make Non-Animal Technologies (NATs) more accessible, transparent, and usable.

Two of these projects — the NATworks Database and the TTV Database (Transparente Tierversuche) — integrate AI-based approaches to process, structure, and provide access to scientific and political information as well as court rulings.

In this talk, Julia Radzwill, biologist and Scientific Officer at DAAE, will introduce the databases, the problems they were built to address, and how they can be used to challenge the status quo in animal-based research. Robert Wulff, IT Administrator and developer of the databases, will then take a look under the hood, providing technical insights into their architecture, implementation, and the role AI plays in turning complex domain specific data into accessible information.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Building AI-Powered Databases to Overcome Outdated Practices and Advance Human-Based Research.

Doctors Against Animal Experiments (DAAE), an NGO based in Cologne, advocates for a phase-out of animal experiments and a shift towards ethical, human-based research. Alongside public outreach, campaigns, and political advocacy, DAAE develops and maintains four databases designed to accelerate this transition and make Non-Animal Technologies (NATs) more accessible, transparent, and usable.

Two of these projects — the NATworks Database and the TTV Database (Transparente Tierversuche) — integrate AI-based approaches to process, structure, and provide access to scientific and political information as well as court rulings.

In this talk, Julia Radzwill, biologist and Scientific Officer at DAAE, will introduce the databases, the problems they were built to address, and how they can be used to challenge the status quo in animal-based research. Robert Wulff, IT Administrator and developer of the databases, will then take a look under the hood, providing technical insights into their architecture, implementation, and the role AI plays in turning complex domain specific data into accessible information.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/c4.openchaos.2026.09.data-against-animal-experiments&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/regional/c4/openchaos/2609-9da9e55c-51a1-42fc-98eb-6a88838f4b3c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/contributors/koeln/open_chaos/2026/h264-sd/openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4&quot;&gt;openchaos-2609-eng-Data_Against_Animal_Experiments_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4">
    <title>Silent but Deadly: Reconstructing Undisclosed Security Vulnerabilities in Public Package Registries (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4</link>
    <description>Research shows that up to 50% of security fixes in open source repositories are committed silently — no CVE, no advisory, no changelog entry — and more than 10% have active exploits in the wild before anyone outside the project knows (Li &amp; Paxson, CCS 2017; Dong et al., DSN 2025).

Traditional detection techniques like binary patch classifiers can tell you whether a patch is a security fix — but not what the vulnerability was or how to exploit it. Until now, reconstruction still required a skilled analyst and hours of work.

This all changes with the advent of Large Language Models. In this talk, we present Lacuna, a tool that diffs two versions of an npm, Maven, or PyPI package and runs a three-phase LLM pipeline to produce a full vulnerability reconstruction — attack scenario, CWE, CVSS vector — and determine whether it was ever disclosed.

In our testing, roughly one in six version bumps in popular packages contained undisclosed security fixes — including packages with tens of millions of weekly downloads. We found silent fixes for SSRF, prototype pollution patches described as a performance improvement, and a critical TLS bypass update with no changelog entry at all.

The uncomfortable implication: any attacker with enough tokens can turn a silent patch into a working exploit. Maintainers who have relied on quiet fixes to buy their users time need to reckon with that. When the window between patch and working exploit has collapsed to minutes, publishing an advisory is no longer optional. Without a CVE, your SBOM lists the dependency clean and your software composition analysis scan stays green. That raises a question the industry hasn&#39;t fully answered: should tools be analysing what actually changed between versions, not just what was disclosed?

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Research shows that up to 50% of security fixes in open source repositories are committed silently — no CVE, no advisory, no changelog entry — and more than 10% have active exploits in the wild before anyone outside the project knows (Li &amp; Paxson, CCS 2017; Dong et al., DSN 2025).

Traditional detection techniques like binary patch classifiers can tell you whether a patch is a security fix — but not what the vulnerability was or how to exploit it. Until now, reconstruction still required a skilled analyst and hours of work.

This all changes with the advent of Large Language Models. In this talk, we present Lacuna, a tool that diffs two versions of an npm, Maven, or PyPI package and runs a three-phase LLM pipeline to produce a full vulnerability reconstruction — attack scenario, CWE, CVSS vector — and determine whether it was ever disclosed.

In our testing, roughly one in six version bumps in popular packages contained undisclosed security fixes — including packages with tens of millions of weekly downloads. We found silent fixes for SSRF, prototype pollution patches described as a performance improvement, and a critical TLS bypass update with no changelog entry at all.

The uncomfortable implication: any attacker with enough tokens can turn a silent patch into a working exploit. Maintainers who have relied on quiet fixes to buy their users time need to reckon with that. When the window between patch and working exploit has collapsed to minutes, publishing an advisory is no longer optional. Without a CVE, your SBOM lists the dependency clean and your software composition analysis scan stays green. That raises a question the industry hasn&#39;t fully answered: should tools be analysing what actually changed between versions, not just what was disclosed?

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110770-silent-but-deadly-reconst&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110770-5cbfcf68-f642-4618-bc33-190f00ccd540.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4&quot;&gt;god2026-110770-eng-Silent_but_Deadly_Reconstructing_Undisclosed_Security_Vulnerabilities_in_Public_Package_Registries_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4">
    <title>Celebrating the 25th Anniversary of OWASP and the 22nd of German Chapter (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4</link>
    <description>Celebrating the 25th Anniversary of OWASP and the 22nd of the German Chapter

Founded in 2001, OWASP began as a grassroots initiative and the debut of the OWASP Top Ten followed soon after.

Established soon after in 2004, the German Chapter has grown to become one of the longest-running chapters in the global community. Join us as we celebrate these milestones with a quick look back at the history and achievements of the German Chapter.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Celebrating the 25th Anniversary of OWASP and the 22nd of the German Chapter

Founded in 2001, OWASP began as a grassroots initiative and the debut of the OWASP Top Ten followed soon after.

Established soon after in 2004, the German Chapter has grown to become one of the longest-running chapters in the global community. Join us as we celebrate these milestones with a quick look back at the history and achievements of the German Chapter.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110760-celebrating-the-25th-anni&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110760-9eb5926c-9506-4803-8e8d-f10c5a305200.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4&quot;&gt;god2026-110760-eng-Celebrating_the_25th_Anniversary_of_OWASP_and_the_22nd_of_German_Chapter_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4">
    <title>Sicher in einen neuen Hafen -- Die Geschichte einer Migration in eine europäische Cloud (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4</link>
    <description>Amerikanische Cloud-Anbieter durch europäische zu ersetzen ist im aktuellen politischen Umfeld gewollt — technisch aber ein Kompromiss, denn europäische Anbieter sind kleiner und bieten entsprechend weniger Komfort- und Sicherheits-Features.

Auch unser Projekt musste in eine europäische Cloud migrieren. Ähnliche Anforderungen wurden auch an andere unserer Projekte gestellt, wodurch ein projektübergreifender Betrieb entstand. Dieser Vortrag zeigt wie wir unseren Betrieb von AWS in einen europäischen Cloud-Dienst überführt haben. Dabei mussten wir inkompatible Sicherheitsanforderungen verschiedener Projekte managen und undokumentierte „Feature“ zähmen, um am Ende einen sicheren langlebigen europäischen Cloudbetrieb zu schaffen.

Der Schwerpunkt liegt auf den sicherheitsrelevanten Entscheidungen — warum wir sie so getroffen haben, welche sich aus unserer Sicht bewährt haben und welche wir im Nachhinein anders treffen würden.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Amerikanische Cloud-Anbieter durch europäische zu ersetzen ist im aktuellen politischen Umfeld gewollt — technisch aber ein Kompromiss, denn europäische Anbieter sind kleiner und bieten entsprechend weniger Komfort- und Sicherheits-Features.

Auch unser Projekt musste in eine europäische Cloud migrieren. Ähnliche Anforderungen wurden auch an andere unserer Projekte gestellt, wodurch ein projektübergreifender Betrieb entstand. Dieser Vortrag zeigt wie wir unseren Betrieb von AWS in einen europäischen Cloud-Dienst überführt haben. Dabei mussten wir inkompatible Sicherheitsanforderungen verschiedener Projekte managen und undokumentierte „Feature“ zähmen, um am Ende einen sicheren langlebigen europäischen Cloudbetrieb zu schaffen.

Der Schwerpunkt liegt auf den sicherheitsrelevanten Entscheidungen — warum wir sie so getroffen haben, welche sich aus unserer Sicht bewährt haben und welche wir im Nachhinein anders treffen würden.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110759-sicher-in-einen-neuen-haf&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110759-3c366f41-426d-4658-a379-c67c32ab5cae.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4&quot;&gt;god2026-110759-deu-Sicher_in_einen_neuen_Hafen_--_Die_Geschichte_einer_Migration_in_eine_europaeische_Cloud_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4">
    <title>How To Fuzz for Logic Bugs? Building Effective Oracles - A Case Study on Site Isolation Bypass Bugs (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4</link>
    <description>Due to the rise of memory-safe languages like Rust, attention shifts towards logic bugs, which do not arise from insecure memory accesses. Identifying these bugs in large and complex codebases is hard, because bugs are mainly triggered by rare edge cases. Fuzzing is a great technique to induce random behavior and observe the edge cases in the application logic that are prone to logic bugs.

However, fuzzing logic bugs requires a bug oracle, to detect whenever the application behavior deviates. Such models are hard to define, if they must infer correct or incorrect behavior based on the applications output. We propose a different approach: Oracles can be implemented effectively by applying small patches on the target application, because they can be defined as invariants that must hold across all random executions. This talk presents this approach exemplary on recent work, detecting site isolation bypass bugs in web browsers.

Site isolation is one of the core security mechanisms of modern browsers. When using site isolation, the browser confines all processing related to a site to its own sandboxed renderer process. This, however, requires the central browser process to keep track of which renderer process belongs to which site. Logic bugs in this implementation, allow attackers to leak sensitive data, such as cookies, or achieve Universal Cross-Site Scripting.

We implemented two oracles, the leak sanitizer and the process sanitizer, that detect a wide range of site isolation bypass bugs. Combined with a fuzzer that targets edge cases in cross-site communication and navigation, our oracles detected four site isolation bugs in Chrome and Firefox.

This basic approach generalizes to other complex applications and classes of logic bugs. In this talk, we will explore how to set up a fuzzer for logic bugs and to inspire you to find logic bugs in more complex applications.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Due to the rise of memory-safe languages like Rust, attention shifts towards logic bugs, which do not arise from insecure memory accesses. Identifying these bugs in large and complex codebases is hard, because bugs are mainly triggered by rare edge cases. Fuzzing is a great technique to induce random behavior and observe the edge cases in the application logic that are prone to logic bugs.

However, fuzzing logic bugs requires a bug oracle, to detect whenever the application behavior deviates. Such models are hard to define, if they must infer correct or incorrect behavior based on the applications output. We propose a different approach: Oracles can be implemented effectively by applying small patches on the target application, because they can be defined as invariants that must hold across all random executions. This talk presents this approach exemplary on recent work, detecting site isolation bypass bugs in web browsers.

Site isolation is one of the core security mechanisms of modern browsers. When using site isolation, the browser confines all processing related to a site to its own sandboxed renderer process. This, however, requires the central browser process to keep track of which renderer process belongs to which site. Logic bugs in this implementation, allow attackers to leak sensitive data, such as cookies, or achieve Universal Cross-Site Scripting.

We implemented two oracles, the leak sanitizer and the process sanitizer, that detect a wide range of site isolation bypass bugs. Combined with a fuzzer that targets edge cases in cross-site communication and navigation, our oracles detected four site isolation bugs in Chrome and Firefox.

This basic approach generalizes to other complex applications and classes of logic bugs. In this talk, we will explore how to set up a fuzzer for logic bugs and to inspire you to find logic bugs in more complex applications.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110767-how-to-fuzz-for-logic-bug&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110767-fcdfd8b5-c47a-44cb-bdcf-5caf970672ca.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4&quot;&gt;god2026-110767-eng-How_To_Fuzz_for_Logic_Bugs_Building_Effective_Oracles_-_A_Case_Study_on_Site_Isolation_Bypass_Bugs_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4">
    <title>How to Hack &quot;Read-Only&quot; SQL MCP Servers Online (Fast) (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4</link>
    <description>Chat Bots und AI Agents werden immer mehr produktiv eingesetzt. Oft sollen diese mit einer SQL Datenbank interagieren können. Wenn lediglich Daten gelesen, aber nicht verändert werden sollen, scheint es sinnvoll einen &quot;Read-Only&quot; SQL MCP Server dafür zu verwenden. Doch was wenn dieser doch nicht so &quot;Read-Only&quot; wie versprochen ist und zum Beispiel der Chatbot zur Kundenberatung auf einmal dazu benutzt werden kann die Preise von Produkten oder Passwörter von Benutzern zu ändern?

Ich habe 19 &quot;Read-Only&quot; SQL MCP Server untersucht und in 18 innerhalb von je 30 Minuten Schwachstellen gefunden; so &quot;Read-Only&quot; waren diese dann doch nicht...

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Chat Bots und AI Agents werden immer mehr produktiv eingesetzt. Oft sollen diese mit einer SQL Datenbank interagieren können. Wenn lediglich Daten gelesen, aber nicht verändert werden sollen, scheint es sinnvoll einen &quot;Read-Only&quot; SQL MCP Server dafür zu verwenden. Doch was wenn dieser doch nicht so &quot;Read-Only&quot; wie versprochen ist und zum Beispiel der Chatbot zur Kundenberatung auf einmal dazu benutzt werden kann die Preise von Produkten oder Passwörter von Benutzern zu ändern?

Ich habe 19 &quot;Read-Only&quot; SQL MCP Server untersucht und in 18 innerhalb von je 30 Minuten Schwachstellen gefunden; so &quot;Read-Only&quot; waren diese dann doch nicht...

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110757-how-to-hack-read-only-sql&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110757-b5c2b975-b007-421a-bd58-d5a51ebbd5d5.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4&quot;&gt;god2026-110757-deu-How_to_Hack_Read-Only_SQL_MCP_Servers_Online_Fast_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4">
    <title>Understanding the Map of Threat Modeling Through the Lens of the TM-BOM (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4</link>
    <description>Threat models usually go out of date as soon as they are created. They reside on the tool used to create the threat model. So a developer without access to the threat modeling tool does not even open the threat model.

On the other hand, threat models that are interoperable come with several advantages. It&#39;s easier to share them with team members. Vendors can be asked to provide their threat models in a ready-to-consume format by purchasers in sensitive industries like healthcare. With the advent of agentic systems, LLMs can even consume raw threat models in JSON format and generate threat models that can be viewed and deliberated upon by human reviewers.

The CycloneDX project is pushing to release the TM-BOM (Threat Modeling Bill of Materials) and is targeting general availability later this year. This session discusses the nuts and bolts of the TM-BOM format. Participants will understand how various pieces like blueprints, business objectives, behaviors, threats, risks, use cases, and controls interact with each other.

To ground this standard in reality, I will share insights from integrating this pre-release schema into an open-source threat modeling platform, exploring the friction points of translating complex data structures into human-centric visualizations.

Outline (20 Minutes)

The Interoperability Problem (3 mins): Why siloed threat models fail developers and compliance teams.

Deconstructing the TM-BOM (7 mins): A focused look at the CycloneDX 2.0 schema and how its core components (Blueprints, Behaviors, Threats, Risks, Controls) interlock.

Agents and the TM-BOM (5 mins): How standardizing into JSON unlocks the ability for agentic systems to reliably consume and generate models for human review.

Implementation Realities (3 mins): Engineering lessons learned mapping a complex JSON standard to visual diagrams.

Q&amp;A (2 mins)

Attendees will leave with a functional understanding of the upcoming CycloneDX 2.0 standard, the operational benefits of interoperable threat models, and how to prepare their security pipelines to generate and consume TM-BOMs.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Threat models usually go out of date as soon as they are created. They reside on the tool used to create the threat model. So a developer without access to the threat modeling tool does not even open the threat model.

On the other hand, threat models that are interoperable come with several advantages. It&#39;s easier to share them with team members. Vendors can be asked to provide their threat models in a ready-to-consume format by purchasers in sensitive industries like healthcare. With the advent of agentic systems, LLMs can even consume raw threat models in JSON format and generate threat models that can be viewed and deliberated upon by human reviewers.

The CycloneDX project is pushing to release the TM-BOM (Threat Modeling Bill of Materials) and is targeting general availability later this year. This session discusses the nuts and bolts of the TM-BOM format. Participants will understand how various pieces like blueprints, business objectives, behaviors, threats, risks, use cases, and controls interact with each other.

To ground this standard in reality, I will share insights from integrating this pre-release schema into an open-source threat modeling platform, exploring the friction points of translating complex data structures into human-centric visualizations.

Outline (20 Minutes)

The Interoperability Problem (3 mins): Why siloed threat models fail developers and compliance teams.

Deconstructing the TM-BOM (7 mins): A focused look at the CycloneDX 2.0 schema and how its core components (Blueprints, Behaviors, Threats, Risks, Controls) interlock.

Agents and the TM-BOM (5 mins): How standardizing into JSON unlocks the ability for agentic systems to reliably consume and generate models for human review.

Implementation Realities (3 mins): Engineering lessons learned mapping a complex JSON standard to visual diagrams.

Q&amp;A (2 mins)

Attendees will leave with a functional understanding of the upcoming CycloneDX 2.0 standard, the operational benefits of interoperable threat models, and how to prepare their security pipelines to generate and consume TM-BOMs.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110762-understanding-the-map-of&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110762-f3cc36ee-f906-4095-a5bb-709c9bfc1c6a.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4&quot;&gt;god2026-110762-eng-Understanding_the_Map_of_Threat_Modeling_Through_the_Lens_of_the_TM-BOM_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4">
    <title>New OWASP Kubernetes Top 10 in Action and Explained (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4</link>
    <description>Kubernetes is the backbone of modern applications with a very fast development cycle. To address new threats the OWASP Kubernetes Top 10 received a major update in 2025. This session brings these theoretical risks to life.

We will review the new 2025 security risks and explain how they work. Then we move into action. Through live practical demonstrations you will see how attackers exploit these flaws to steal secrets, escape containers, or take over whole clusters.

For every attack shown we immediately switch to defense. You will learn how to detect these malicious actions and protect your workloads using cloud native tools.

This presentation is for engineers and security professionals who want a clear understanding of the new 2025 OWASP standard combined with hands-on hacking and defense.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Kubernetes is the backbone of modern applications with a very fast development cycle. To address new threats the OWASP Kubernetes Top 10 received a major update in 2025. This session brings these theoretical risks to life.

We will review the new 2025 security risks and explain how they work. Then we move into action. Through live practical demonstrations you will see how attackers exploit these flaws to steal secrets, escape containers, or take over whole clusters.

For every attack shown we immediately switch to defense. You will learn how to detect these malicious actions and protect your workloads using cloud native tools.

This presentation is for engineers and security professionals who want a clear understanding of the new 2025 OWASP standard combined with hands-on hacking and defense.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110768-new-owasp-kubernetes-top&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110768-584a3c41-0196-45d5-b675-945458cc9b6d.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4&quot;&gt;god2026-110768-eng-New_OWASP_Kubernetes_Top_10_in_Action_and_Explained_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110750-eng-Keynote_sd.mp4">
    <title>Keynote (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110750-eng-Keynote_sd.mp4</link>
    <description>AI is creating real breakthroughs, but also an ocean of slop, hype, fear, and confusion. Engineers are declared obsolete. Agentic AI is treated as magic. Security teams are asked to protect systems that are changing faster than their risk models. No wonder many of us feel dazed.

This keynote offers a free therapy session for the AI-overwhelmed, including a grounded path through the chaos from your therapist. What are the truths we can rely on? Which AI risks matter most? How do we scope security concerns without drowning in them? And what about our careers?

Bring your questions. There will be tissues.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      AI is creating real breakthroughs, but also an ocean of slop, hype, fear, and confusion. Engineers are declared obsolete. Agentic AI is treated as magic. Security teams are asked to protect systems that are changing faster than their risk models. No wonder many of us feel dazed.

This keynote offers a free therapy session for the AI-overwhelmed, including a grounded path through the chaos from your therapist. What are the truths we can rely on? Which AI risks matter most? How do we scope security concerns without drowning in them? And what about our careers?

Bring your questions. There will be tissues.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110750-keynote&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110750-5f4583b8-b579-4c38-9771-e4e2e0eb9ac4.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110750-eng-Keynote_sd.mp4&quot;&gt;god2026-110750-eng-Keynote_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4">
    <title>OWASP Cornucopia - Gamifying AI Threat Modeling and Security Requirement Analysis (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4</link>
    <description>Shift-left doesn&#39;t start with scanning the code for security vulnerabilities; it begins with designing for security.

Too often, the shift-left mantra consists of implementing (AI-powered) code scanning and applying AI-powered security fixes for remediation. Also, don&#39;t forget to implement the AI-powered benchmark for AI-powered Security Fixes. Now, to be clear, I am not actually telling you to stop using these tools — if they work for you — instead, we should ask ourselves:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

In order to support that second question in particular, we have created the next version of OWASP Cornucopia (see: https://cybersecgames.com/pages/owasp-cornucopia-threat-modeling-collection).

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams in identifying security requirements in Agile, conventional, and formal development processes. It is language, platform, and technology-agnostic.

The formerly titled &quot;Cornucopia — Ecommerce Website Edition&quot; is now &quot;Cornucopia — Website App Edition&quot;. This edition was originally created in August 2012, released as v1.0 in February 2013, and has undergone several minor updates/releases over the following ten to fifteen years. This has been substantially updated in v2.0, in which the most noticeable change was an update of the OWASP ASVS mapping from ASVS v3.0 to v4.0, together with the creation of translations into six languages (EN, ES, FR, NL, NO-NB, and PT-BR) due to the efforts of past and current volunteers.

The new version, available in 11 languages (EN, ES, FR, HI, NL, NO-NB, PT-PT, PT-BR, RU, UK), will include all new cards and text that covers all OWASP ASVS 5.0 requirements and links them to more than 200 unique common attack patterns (CAPEC). Each of the common attack patterns will have a unique set of ASVS requirements, which means that you never need to stop playing the game! You will always be able to return to the same card to discover new threats and security requirements to consider when building your software. Additionally, we are publishing the OWASP Cornucopia Companion Edition that comes with 6 companion suits (see: https://cornucopia.owasp.org/edition/companion) covering new topics: Agentic AI (AAI), Automated Threats (BOT), Cloud (CLD), Frontend (FRE), Large Language Models (LLM), and DevOps (DVO). A suit in the companion deck may replace (or be used in addition to) suites in the existing Website Edition so that the players can add a specific focus to their threat modeling: For example, say you are building an LLM application and want to perform threat modeling specifically for LLM. You would then use the OWASP Cornucopia Website Edition and the LLM companion suite as your elected OWASP Cornucopia focus area.

What&#39;s more, it is now possible to create your OWASP Cornucopia Threat Model in OWASP Threat Dragon using their brand new EoP Games diagram. The diagram allows you to easily select the right card from the OWASP Cornucopia suite and connect it directly to your threat model in OWASP Threat Dragon, thanks to the combined efforts of volunteers at Universidad Católica del Uruguay and the OWASP Threat Dragon project.

All project leaders and contributors to the OWASP projects that have provided valuable input and guidance to OWASP Top 10, OWASP AISVS and the OWASP GenAI Security project. We also want to thank the people and contributors to Mitre&#39;s Common Attack Pattern Enumeration and Classification (CAPEC™) and Atlas, together with CSA Cloud Controls Matrix, which are all used in the cross-references provided.

Failing to regularly assess your security isn&#39;t only costly; it can leave you vulnerable to threats. Several companies have implemented OWASP Cornucopia as part of their SDLC and use it for security requirements analysis, threat modeling, and secure design for every sprint and every user story. You should do the same! Don&#39;t let your business spiral out of control; consciously assess how you are doing by continuously threat-modeling your applications and infrastructure. To get started scaling your threat modeling efforts, OWASP Cornucopia v3.0 is the perfect tool.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Shift-left doesn&#39;t start with scanning the code for security vulnerabilities; it begins with designing for security.

Too often, the shift-left mantra consists of implementing (AI-powered) code scanning and applying AI-powered security fixes for remediation. Also, don&#39;t forget to implement the AI-powered benchmark for AI-powered Security Fixes. Now, to be clear, I am not actually telling you to stop using these tools — if they work for you — instead, we should ask ourselves:

What are we working on?
What can go wrong?
What are we going to do about it?
Did we do a good job?

In order to support that second question in particular, we have created the next version of OWASP Cornucopia (see: https://cybersecgames.com/pages/owasp-cornucopia-threat-modeling-collection).

OWASP Cornucopia is a mechanism in the form of a card game to assist software development teams in identifying security requirements in Agile, conventional, and formal development processes. It is language, platform, and technology-agnostic.

The formerly titled &quot;Cornucopia — Ecommerce Website Edition&quot; is now &quot;Cornucopia — Website App Edition&quot;. This edition was originally created in August 2012, released as v1.0 in February 2013, and has undergone several minor updates/releases over the following ten to fifteen years. This has been substantially updated in v2.0, in which the most noticeable change was an update of the OWASP ASVS mapping from ASVS v3.0 to v4.0, together with the creation of translations into six languages (EN, ES, FR, NL, NO-NB, and PT-BR) due to the efforts of past and current volunteers.

The new version, available in 11 languages (EN, ES, FR, HI, NL, NO-NB, PT-PT, PT-BR, RU, UK), will include all new cards and text that covers all OWASP ASVS 5.0 requirements and links them to more than 200 unique common attack patterns (CAPEC). Each of the common attack patterns will have a unique set of ASVS requirements, which means that you never need to stop playing the game! You will always be able to return to the same card to discover new threats and security requirements to consider when building your software. Additionally, we are publishing the OWASP Cornucopia Companion Edition that comes with 6 companion suits (see: https://cornucopia.owasp.org/edition/companion) covering new topics: Agentic AI (AAI), Automated Threats (BOT), Cloud (CLD), Frontend (FRE), Large Language Models (LLM), and DevOps (DVO). A suit in the companion deck may replace (or be used in addition to) suites in the existing Website Edition so that the players can add a specific focus to their threat modeling: For example, say you are building an LLM application and want to perform threat modeling specifically for LLM. You would then use the OWASP Cornucopia Website Edition and the LLM companion suite as your elected OWASP Cornucopia focus area.

What&#39;s more, it is now possible to create your OWASP Cornucopia Threat Model in OWASP Threat Dragon using their brand new EoP Games diagram. The diagram allows you to easily select the right card from the OWASP Cornucopia suite and connect it directly to your threat model in OWASP Threat Dragon, thanks to the combined efforts of volunteers at Universidad Católica del Uruguay and the OWASP Threat Dragon project.

All project leaders and contributors to the OWASP projects that have provided valuable input and guidance to OWASP Top 10, OWASP AISVS and the OWASP GenAI Security project. We also want to thank the people and contributors to Mitre&#39;s Common Attack Pattern Enumeration and Classification (CAPEC™) and Atlas, together with CSA Cloud Controls Matrix, which are all used in the cross-references provided.

Failing to regularly assess your security isn&#39;t only costly; it can leave you vulnerable to threats. Several companies have implemented OWASP Cornucopia as part of their SDLC and use it for security requirements analysis, threat modeling, and secure design for every sprint and every user story. You should do the same! Don&#39;t let your business spiral out of control; consciously assess how you are doing by continuously threat-modeling your applications and infrastructure. To get started scaling your threat modeling efforts, OWASP Cornucopia v3.0 is the perfect tool.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110763-owasp-cornucopia-gamifyin&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110763-af2068b9-f97b-45ed-8c07-1f3e9ae5fbd5.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4&quot;&gt;god2026-110763-eng-OWASP_Cornucopia_-_Gamifying_AI_Threat_Modeling_and_Security_Requirement_Analysis_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110758-deu-Public_Money_Public_Containers_sd.mp4">
    <title>Public Money, Public Containers (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110758-deu-Public_Money_Public_Containers_sd.mp4</link>
    <description>Moderne digitale Verwaltungsinfrastrukturen setzen auf eine containerbasierte Infrastruktur. Doch woher stammen die sicheren Container-Images? Derzeit stammen sie überwiegend von US-Anbietern, was mit all den bekannten Risiken hinsichtlich Anbieterabhängigkeit, Datenhoheit und Schwachstellen in der Lieferkette einhergeht. In einer Zeit, in der sich geopolitische Rahmenbedingungen innerhalb weniger Wochen ändern können und Angriffe auf die Software-Lieferkette (Shai-Hulud, npm-Würmer, kompromittierte Basis-Images) zur Norm geworden sind, stellt dies ein strategisches Problem dar.

Im Rahmen der Secure Government Container Initiative (SGCI, ebenfalls Teil der sSDLC-Strategie) und der Plattform container.gov.de stellt ZenDiS für den Bund, die Länder und die öffentliche IT von openCode verifizierte, gehärtete Container-Images bereit, als offene Bausteine, die in Zusammenarbeit mit der Community entwickelt wurden. Wir berichten aus erster Hand: Wie härten wir Container gemäß den BSI-Standards und NIST SP 800-190 ab? Welche Toolchain entsteht dabei? Wo stehen wir nach der ersten Einrichtungsphase und was kann noch getan werden, um den Erfolg dieses Projekts letztendlich sicherzustellen?

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Moderne digitale Verwaltungsinfrastrukturen setzen auf eine containerbasierte Infrastruktur. Doch woher stammen die sicheren Container-Images? Derzeit stammen sie überwiegend von US-Anbietern, was mit all den bekannten Risiken hinsichtlich Anbieterabhängigkeit, Datenhoheit und Schwachstellen in der Lieferkette einhergeht. In einer Zeit, in der sich geopolitische Rahmenbedingungen innerhalb weniger Wochen ändern können und Angriffe auf die Software-Lieferkette (Shai-Hulud, npm-Würmer, kompromittierte Basis-Images) zur Norm geworden sind, stellt dies ein strategisches Problem dar.

Im Rahmen der Secure Government Container Initiative (SGCI, ebenfalls Teil der sSDLC-Strategie) und der Plattform container.gov.de stellt ZenDiS für den Bund, die Länder und die öffentliche IT von openCode verifizierte, gehärtete Container-Images bereit, als offene Bausteine, die in Zusammenarbeit mit der Community entwickelt wurden. Wir berichten aus erster Hand: Wie härten wir Container gemäß den BSI-Standards und NIST SP 800-190 ab? Welche Toolchain entsteht dabei? Wo stehen wir nach der ersten Einrichtungsphase und was kann noch getan werden, um den Erfolg dieses Projekts letztendlich sicherzustellen?

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110758-public-money-public-conta&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110758-964997f6-2ed3-4e85-925b-659771d25a08.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110758-deu-Public_Money_Public_Containers_sd.mp4&quot;&gt;god2026-110758-deu-Public_Money_Public_Containers_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4">
    <title>Agentic AI Gateway Enforcement of the OWASP Top 10 (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4</link>
    <description>The OWASP Top 10 for Agentic Applications 2026 clearly outlines risks like prompt injection, tool misuse, excessive agency, rogue and compromised agents, and untraceable actions. This talk shows how an open source tool addresses the risks as a control platform, a switchboard between the model and its actions. The separation means any hostile or compromised model is bound and can&#39;t reach or bypass these controls.

    Tool misuse and excessive agency hit per-action permission tiers that auto-allow, require human approval, or block.
    Compromised and rogue agents hit a gate so an &quot;evil model&quot; can&#39;t elevate.
    Untraceable action hits an append-only, hash-chained, signed audit log.
    Skill supply chain hits a signature verification at load.

A live agent demo shows the risks, controls, source code, and design architecture. The reference implementation maps to the sovereignty posture the EU formalized in its June 2026 tech package.

Documentation and source: https://wirken.ai

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      The OWASP Top 10 for Agentic Applications 2026 clearly outlines risks like prompt injection, tool misuse, excessive agency, rogue and compromised agents, and untraceable actions. This talk shows how an open source tool addresses the risks as a control platform, a switchboard between the model and its actions. The separation means any hostile or compromised model is bound and can&#39;t reach or bypass these controls.

    Tool misuse and excessive agency hit per-action permission tiers that auto-allow, require human approval, or block.
    Compromised and rogue agents hit a gate so an &quot;evil model&quot; can&#39;t elevate.
    Untraceable action hits an append-only, hash-chained, signed audit log.
    Skill supply chain hits a signature verification at load.

A live agent demo shows the risks, controls, source code, and design architecture. The reference implementation maps to the sovereignty posture the EU formalized in its June 2026 tech package.

Documentation and source: https://wirken.ai

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110751-agentic-ai-gateway-enforc&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110751-dfb213c8-cf0b-4ff1-a932-76dba9b66521.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4&quot;&gt;god2026-110751-eng-Agentic_AI_Gateway_Enforcement_of_the_OWASP_Top_10_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4">
    <title>Zeit für OAuth 2.1 - Security Best Practices als neuer Standard (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4</link>
    <description>Implementieren Sie OAuth noch nach einem Spec von 2012? Dann ist Ihre Anwendung vermutlich unsicher! OAuth 2.0 hat sich in 13 Jahren durch ein Labyrinth von RFCs und Best Practices entwickelt – Implicit Flow ist deprecated, PKCE ist Pflicht, Password Grant ein No-Go. Aber wer weiß das schon alles?

OAuth 2.1 räumt endlich auf: Ein Draft, der alle modernen Security Best Practices vereint und unsichere Flows eliminiert. Klingt perfekt? Ist es auch! Nur leider wendet ihn fast niemand an.

In diesem Talk zeigt Ihnen Martina Kraus, warum OAuth 2.1 Ihre OAuth-Implementierung von Grund auf sicherer macht, welche Breaking Changes auf Sie warten und wie Sie schon heute damit arbeiten können.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Implementieren Sie OAuth noch nach einem Spec von 2012? Dann ist Ihre Anwendung vermutlich unsicher! OAuth 2.0 hat sich in 13 Jahren durch ein Labyrinth von RFCs und Best Practices entwickelt – Implicit Flow ist deprecated, PKCE ist Pflicht, Password Grant ein No-Go. Aber wer weiß das schon alles?

OAuth 2.1 räumt endlich auf: Ein Draft, der alle modernen Security Best Practices vereint und unsichere Flows eliminiert. Klingt perfekt? Ist es auch! Nur leider wendet ihn fast niemand an.

In diesem Talk zeigt Ihnen Martina Kraus, warum OAuth 2.1 Ihre OAuth-Implementierung von Grund auf sicherer macht, welche Breaking Changes auf Sie warten und wie Sie schon heute damit arbeiten können.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110766-zeit-fur-oauth-21-securit&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110766-c132e9ae-87da-4708-8a84-ad6c14ce1660.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4&quot;&gt;god2026-110766-deu-Zeit_fuer_OAuth_21_-_Security_Best_Practices_als_neuer_Standard_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4">
    <title>What LLMs Can Do in Pentesting and Code Security (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4</link>
    <description>Large language models are starting to change both sides of application security: offensive work such as black-box penetration testing, and defensive work such as code review and vulnerability detection in source code.

In this talk, I present practical lessons from my academic and independent work in both areas: AutoPentest, my research on autonomous black-box pentesting with LLM agents; Vuldra, my work on LLM-assisted static code analysis; and my recent hands-on evaluation of OpenAI Codex Security on a real open-source project.

On the offensive side, I show what happens when an LLM agent is asked to carry out a black-box penetration test with a high degree of autonomy. I explain the architecture behind AutoPentest, including specialized worker agents structured around OWASP Top 10-relevant web vulnerability areas, and show where the system still struggles in longer attack chains.

In my evaluation on three Hack The Box machines, AutoPentest completed 15 to 26 percent of subtasks and slightly outperformed a manual ChatGPT-based baseline on one target.

On the defensive side, I explored two ways of using LLMs for code security testing.

First, I discuss Vuldra as an example of how LLMs can be used for static code analysis, integrating them with traditional SAST tools.

Second, I present my evaluation of Codex Security on TorMap, where I looked at real findings, proposed fixes, and practical limits in a developer workflow.

The main message of the talk is simple: LLMs can already help security teams on both the attacker and defender side, but their strengths and weaknesses are different.

Attendees will leave with a realistic view of where LLMs are already useful, where they still fail, and how to evaluate such tools in their own environment without treating them as magic.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Large language models are starting to change both sides of application security: offensive work such as black-box penetration testing, and defensive work such as code review and vulnerability detection in source code.

In this talk, I present practical lessons from my academic and independent work in both areas: AutoPentest, my research on autonomous black-box pentesting with LLM agents; Vuldra, my work on LLM-assisted static code analysis; and my recent hands-on evaluation of OpenAI Codex Security on a real open-source project.

On the offensive side, I show what happens when an LLM agent is asked to carry out a black-box penetration test with a high degree of autonomy. I explain the architecture behind AutoPentest, including specialized worker agents structured around OWASP Top 10-relevant web vulnerability areas, and show where the system still struggles in longer attack chains.

In my evaluation on three Hack The Box machines, AutoPentest completed 15 to 26 percent of subtasks and slightly outperformed a manual ChatGPT-based baseline on one target.

On the defensive side, I explored two ways of using LLMs for code security testing.

First, I discuss Vuldra as an example of how LLMs can be used for static code analysis, integrating them with traditional SAST tools.

Second, I present my evaluation of Codex Security on TorMap, where I looked at real findings, proposed fixes, and practical limits in a developer workflow.

The main message of the talk is simple: LLMs can already help security teams on both the attacker and defender side, but their strengths and weaknesses are different.

Attendees will leave with a realistic view of where LLMs are already useful, where they still fail, and how to evaluate such tools in their own environment without treating them as magic.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110754-what-llms-can-do-in-pente&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110754-69dc1dd7-b5c4-4f86-921f-3bf98d0b7569.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4&quot;&gt;god2026-110754-eng-What_LLMs_Can_Do_in_Pentesting_and_Code_Security_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4">
    <title>Indirect Prompt Injection in the Wild: An Empirical Study of Prevalence, Techniques, and Objectives (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4</link>
    <description>As LLMs are increasingly integrated into systems that browse, retrieve, summarize, and act on web content, webpages have become an untrusted input vector for downstream model behavior. This enables site owners, contributors, and adversaries to embed instructions directly in web resources, i.e., indirect prompt injections. While prior work demonstrates such attacks in controlled settings, their prevalence, deployment, and real-world impact remain unclear.

We present one of the first large-scale empirical analyses of indirect prompt injections in webpages and HTTP responses. Analyzing 1.2B URLs from 24.8M hosts, we identify 15.3K validated instances across 11.7K pages. These are not isolated cases: a small number of recurring templates account for most cases. We characterize their objectives, delivery mechanisms, visibility, persistence, and impact, revealing a heterogeneous ecosystem spanning disruptive prompts, reputation manipulation, content-protection directives, and AI-bot detection, targeting systems such as crawlers, search pipelines, customer-support agents, and hiring workflows.

A key finding is that most instructions target machines rather than humans: about 70% appear in non-rendered HTML (e.g., headers, comments, metadata), and many visible cases are hidden via rendering techniques. To assess practical risk, we run 5,200 controlled experiments across 13 models and four webpage representations. Our results show compliance is limited but non-negligible, reaching up to 8% for smaller models on plain-text inputs, while structured representations reduce compliance by preserving structural cues. Overall, prompt-based interference is already present in the web ecosystem and represents a growing source of tension between LLM-driven automation and the sites it consumes.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      As LLMs are increasingly integrated into systems that browse, retrieve, summarize, and act on web content, webpages have become an untrusted input vector for downstream model behavior. This enables site owners, contributors, and adversaries to embed instructions directly in web resources, i.e., indirect prompt injections. While prior work demonstrates such attacks in controlled settings, their prevalence, deployment, and real-world impact remain unclear.

We present one of the first large-scale empirical analyses of indirect prompt injections in webpages and HTTP responses. Analyzing 1.2B URLs from 24.8M hosts, we identify 15.3K validated instances across 11.7K pages. These are not isolated cases: a small number of recurring templates account for most cases. We characterize their objectives, delivery mechanisms, visibility, persistence, and impact, revealing a heterogeneous ecosystem spanning disruptive prompts, reputation manipulation, content-protection directives, and AI-bot detection, targeting systems such as crawlers, search pipelines, customer-support agents, and hiring workflows.

A key finding is that most instructions target machines rather than humans: about 70% appear in non-rendered HTML (e.g., headers, comments, metadata), and many visible cases are hidden via rendering techniques. To assess practical risk, we run 5,200 controlled experiments across 13 models and four webpage representations. Our results show compliance is limited but non-negligible, reaching up to 8% for smaller models on plain-text inputs, while structured representations reduce compliance by preserving structural cues. Overall, prompt-based interference is already present in the web ecosystem and represents a growing source of tension between LLM-driven automation and the sites it consumes.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110753-indirect-prompt-injection&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110753-0cb083d4-9bba-4464-b66c-2913b8698752.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4&quot;&gt;god2026-110753-eng-Indirect_Prompt_Injection_in_the_Wild_An_Empirical_Study_of_Prevalence_Techniques_and_Objectives_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4">
    <title>OWASP AISVS: Bringing Order to AI Security Chaos (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4</link>
    <description>Artificial intelligence is becoming a core building block of modern applications, yet the way we secure software has not kept pace with the unique properties of AI systems. Traditional approaches often rely on static assumptions and deterministic behavior, while AI introduces probabilistic outputs, dynamic decision-making, and new forms of interaction that challenge established security practices.

The OWASP AI Security Verification Standard (AISVS) is an effort to address this gap by providing a structured and testable framework for securing AI-enabled applications. It builds on the idea that security should be verifiable and measurable, and adapts this principle to systems that incorporate machine learning models, large language models, and autonomous components.

This talk presents the motivation behind AISVS, its design principles, and how it defines security requirements that can be consistently evaluated. It explores how developers and security teams can use AISVS to move from informal or reactive approaches toward a more systematic way of validating the security of AI systems throughout their lifecycle.

By focusing on clarity, practical applicability, and alignment with real-world development workflows, AISVS aims to become a foundation for building trust in AI-driven applications. Attendees will gain an understanding of how a verification standard can help bring structure and confidence to a rapidly evolving and often uncertain security landscape.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Artificial intelligence is becoming a core building block of modern applications, yet the way we secure software has not kept pace with the unique properties of AI systems. Traditional approaches often rely on static assumptions and deterministic behavior, while AI introduces probabilistic outputs, dynamic decision-making, and new forms of interaction that challenge established security practices.

The OWASP AI Security Verification Standard (AISVS) is an effort to address this gap by providing a structured and testable framework for securing AI-enabled applications. It builds on the idea that security should be verifiable and measurable, and adapts this principle to systems that incorporate machine learning models, large language models, and autonomous components.

This talk presents the motivation behind AISVS, its design principles, and how it defines security requirements that can be consistently evaluated. It explores how developers and security teams can use AISVS to move from informal or reactive approaches toward a more systematic way of validating the security of AI systems throughout their lifecycle.

By focusing on clarity, practical applicability, and alignment with real-world development workflows, AISVS aims to become a foundation for building trust in AI-driven applications. Attendees will gain an understanding of how a verification standard can help bring structure and confidence to a rapidly evolving and often uncertain security landscape.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110756-owasp-aisvs-bringing-orde&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110756-509b974a-6131-437c-b909-6a77b89c3e69.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4&quot;&gt;god2026-110756-eng-OWASP_AISVS_Bringing_Order_to_AI_Security_Chaos_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4">
    <title>CRA effizient und nachhaltig umsetzen (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4</link>
    <description>Der Cyber Resilience Act (CRA) stellt Sicherheitsanforderungen an Hersteller und Anbieter von Produkten mit digitalen Elementen. Viele Unternehmen haben bereits ein grundlegendes Sicherheitsniveau, doch der gezielte Abgleich mit den CRA-Anforderungen ist aufwändig und zeigt häufig unerwartete Lücken.

Der Vortrag stellt ein Vorgehen vor, mit dem sich diese Gaps effizient identifizieren und daraus priorisierte Maßnahmen ableiten lassen. Die Basis stellt das OWASP SAMM Framework dar, das als Best-Practice für Secure Software Development Lifecycle (SSDLC) auch eine Standortbestimmung und kontinuierliche Weiterentwicklung mit individuellen Schwerpunkten ermöglicht.

Ein hierfür entwickeltes Mapping von CRA auf den OWASP SAMM ermöglicht ein strukturiertes CRA-Assessment und kurzfristig eine zielgerichtete Umsetzung der regulatorischen Anforderungen. Gleichzeitig wird ein erweitertes Rahmenwerk geschaffen, das hilft, den sicheren Entwicklungsprozess langfristig zu verbessern. Das Vorgehen erlaubt die Automatisierung einzelner Aufgaben wie dem Compliance-Check, reduziert somit den manuellen Aufwand und beschleunigt die Umsetzung. Praxisbeispiele verdeutlichen, wie Unternehmen so nicht nur effizient und ggf. KI-unterstützt CRA-Compliance erreichen, sondern einen nachhaltigen und resilienten SSDLC etablieren.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Der Cyber Resilience Act (CRA) stellt Sicherheitsanforderungen an Hersteller und Anbieter von Produkten mit digitalen Elementen. Viele Unternehmen haben bereits ein grundlegendes Sicherheitsniveau, doch der gezielte Abgleich mit den CRA-Anforderungen ist aufwändig und zeigt häufig unerwartete Lücken.

Der Vortrag stellt ein Vorgehen vor, mit dem sich diese Gaps effizient identifizieren und daraus priorisierte Maßnahmen ableiten lassen. Die Basis stellt das OWASP SAMM Framework dar, das als Best-Practice für Secure Software Development Lifecycle (SSDLC) auch eine Standortbestimmung und kontinuierliche Weiterentwicklung mit individuellen Schwerpunkten ermöglicht.

Ein hierfür entwickeltes Mapping von CRA auf den OWASP SAMM ermöglicht ein strukturiertes CRA-Assessment und kurzfristig eine zielgerichtete Umsetzung der regulatorischen Anforderungen. Gleichzeitig wird ein erweitertes Rahmenwerk geschaffen, das hilft, den sicheren Entwicklungsprozess langfristig zu verbessern. Das Vorgehen erlaubt die Automatisierung einzelner Aufgaben wie dem Compliance-Check, reduziert somit den manuellen Aufwand und beschleunigt die Umsetzung. Praxisbeispiele verdeutlichen, wie Unternehmen so nicht nur effizient und ggf. KI-unterstützt CRA-Compliance erreichen, sondern einen nachhaltigen und resilienten SSDLC etablieren.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110765-cra-effizient-und-nachhal&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110765-76ed3440-6570-4c39-8e96-a18de855315a.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4&quot;&gt;god2026-110765-deu-CRA_effizient_und_nachhaltig_umsetzen_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4">
    <title>Race Against The Workflows: Stealing GitHub Tokens from Docker Images (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4</link>
    <description>CI/CD pipelines have become prime targets for supply chain attacks, enabling persistent compromise of distribution builds and secrets. In the GitHub Actions ecosystem specifically, documented attack techniques typically focus on developer mistakes, such as environment injections and pwn requests. However, research scanning Docker Hub has revealed a different class of vulnerability: over 240,000 GitHub authentication tokens leaked through a seemingly benign workflow pattern using legitimate, official actions, in particular the combination of actions/checkout and the common COPY . Docker antipattern.

This presentation will explain the complete vulnerability chain from workflow execution to token exposure, demonstrate exploitation techniques that overcome default security mechanisms — racing against token expiration while exploiting elevated workflow permissions — and provide a multi-layered defense strategy including critical action version updates and Docker hardening best practices.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      CI/CD pipelines have become prime targets for supply chain attacks, enabling persistent compromise of distribution builds and secrets. In the GitHub Actions ecosystem specifically, documented attack techniques typically focus on developer mistakes, such as environment injections and pwn requests. However, research scanning Docker Hub has revealed a different class of vulnerability: over 240,000 GitHub authentication tokens leaked through a seemingly benign workflow pattern using legitimate, official actions, in particular the combination of actions/checkout and the common COPY . Docker antipattern.

This presentation will explain the complete vulnerability chain from workflow execution to token exposure, demonstrate exploitation techniques that overcome default security mechanisms — racing against token expiration while exploiting elevated workflow permissions — and provide a multi-layered defense strategy including critical action version updates and Docker hardening best practices.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110769-race-against-the-workflow&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110769-5d31d624-1c26-499c-aba3-1c53ccf3d143.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4&quot;&gt;god2026-110769-eng-Race_Against_The_Workflows_Stealing_GitHub_Tokens_from_Docker_Images_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4">
    <title>Vier grüne Häkchen, trotzdem gehackt: Threat Modeling für KI-Agenten (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4</link>
    <description>Eine E-Mail liegt im Posteingang. Niemand öffnet sie, niemand klickt. Tage später fragt jemand seinen KI-Assistenten nach den letzten Mails — und der Agent schickt still interne Daten an einen fremden Server. So lief EchoLeak gegen Microsoft Copilot (CVE-2025-32711, CVSS 9.3): kein Exploit-Code, keine kaputte Authentifizierung. Jede Komponente hatte ihr Security-Review bestanden. Der Angriff lebte im Pfad dazwischen.

Wer agentenbasierte Systeme baut, kennt das Muster: Wir prüfen Komponenten einzeln, Angreifer denken in Ketten. Sobald ein Agent Daten abruft, Aufgaben plant, Tools aufruft, sich Dinge merkt und mit anderen Agenten redet, entstehen Angriffspfade quer über Vertrauensgrenzen, die kein Per-Komponenten-Review sichtbar macht. Gerade im Kontext von Agentic AI werden dabei die Grenzen klassischer STRIDE-Analysen sichtbar, weil sich Risiken oft erst entlang von Daten-, Entscheidungs- und Tool-Ketten über mehrere Komponenten hinweg entfalten.

Ich zeige eine Methode, kein weiteres Framework zum Auswendiglernen. Die Fünf-Zonen-Brille — Eingabe, Planung, Tool-Ausführung, Speicher, Agent-zu-Agent-Kommunikation — sagt, wo man hinschauen muss; die OWASP Top 10 for Agentic AI Applications sagen, was man dort findet. Wir gehen drei reale Architekturen durch: RAG-Pipeline-Poisoning, Missbrauch einer MCP-Tool-Chain und eine Multi-Agent-Kaskade. Für jede bauen wir einen Attack Tree und trennen die Kontrollen, die strukturell halten (Tool-Scoping pro Aufgabe, Egress-Inspektion, Credential-Trennung), von den prompt-basierten, die nur beruhigend klingen.

Am Ende habt ihr eine wiederholbare Routine für euer eigenes Agentic AI System: Zonen kartieren, Pfade ablaufen, einen Baum bauen, Single Points of Failure finden, Kontrollen anhängen und validieren.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Eine E-Mail liegt im Posteingang. Niemand öffnet sie, niemand klickt. Tage später fragt jemand seinen KI-Assistenten nach den letzten Mails — und der Agent schickt still interne Daten an einen fremden Server. So lief EchoLeak gegen Microsoft Copilot (CVE-2025-32711, CVSS 9.3): kein Exploit-Code, keine kaputte Authentifizierung. Jede Komponente hatte ihr Security-Review bestanden. Der Angriff lebte im Pfad dazwischen.

Wer agentenbasierte Systeme baut, kennt das Muster: Wir prüfen Komponenten einzeln, Angreifer denken in Ketten. Sobald ein Agent Daten abruft, Aufgaben plant, Tools aufruft, sich Dinge merkt und mit anderen Agenten redet, entstehen Angriffspfade quer über Vertrauensgrenzen, die kein Per-Komponenten-Review sichtbar macht. Gerade im Kontext von Agentic AI werden dabei die Grenzen klassischer STRIDE-Analysen sichtbar, weil sich Risiken oft erst entlang von Daten-, Entscheidungs- und Tool-Ketten über mehrere Komponenten hinweg entfalten.

Ich zeige eine Methode, kein weiteres Framework zum Auswendiglernen. Die Fünf-Zonen-Brille — Eingabe, Planung, Tool-Ausführung, Speicher, Agent-zu-Agent-Kommunikation — sagt, wo man hinschauen muss; die OWASP Top 10 for Agentic AI Applications sagen, was man dort findet. Wir gehen drei reale Architekturen durch: RAG-Pipeline-Poisoning, Missbrauch einer MCP-Tool-Chain und eine Multi-Agent-Kaskade. Für jede bauen wir einen Attack Tree und trennen die Kontrollen, die strukturell halten (Tool-Scoping pro Aufgabe, Egress-Inspektion, Credential-Trennung), von den prompt-basierten, die nur beruhigend klingen.

Am Ende habt ihr eine wiederholbare Routine für euer eigenes Agentic AI System: Zonen kartieren, Pfade ablaufen, einen Baum bauen, Single Points of Failure finden, Kontrollen anhängen und validieren.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110764-vier-grune-hakchen-trotzd&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110764-0b883d09-1c27-4894-a46e-1e23b5528aa1.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4&quot;&gt;god2026-110764-deu-Vier_gruene_Haekchen_trotzdem_gehackt_Threat_Modeling_fuer_KI-Agenten_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4">
    <title>Hackbots under control: Methodology for Autonomous Pentesters (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4</link>
    <description>Autonomous pentesting tools have matured to the point where they can reliably find vulnerabilities, but finding vulnerabilities is not the same as doing a professional pentest. Bug bounty hunting optimizes for high-severity impact while a client engagement requires systematic coverage against a framework, with every control checked.

In this talk we will explore how we designed an internal solution that layers the OWASP ASVS framework on top of existing agentic testing products. We will cover what we put in place to get reliable results, the guardrails we designed to ensure safe behavior in client environments, and how our harness improves the coverage of agentic testing solutions.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Autonomous pentesting tools have matured to the point where they can reliably find vulnerabilities, but finding vulnerabilities is not the same as doing a professional pentest. Bug bounty hunting optimizes for high-severity impact while a client engagement requires systematic coverage against a framework, with every control checked.

In this talk we will explore how we designed an internal solution that layers the OWASP ASVS framework on top of existing agentic testing products. We will cover what we put in place to get reliable results, the guardrails we designed to ensure safe behavior in client environments, and how our harness improves the coverage of agentic testing solutions.

Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110752-hackbots-under-control-me&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110752-89354a50-d435-4899-ab5d-eb6e4a37150e.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4&quot;&gt;god2026-110752-eng-Hackbots_under_control_Methodology_for_Autonomous_Pentesters_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4">
    <title>Chapter Lead: Thanks &amp; meet you next year (god2026)</title>
    <link>https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4</link>
    <description>Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Licensed to the public under https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/god2026-110761-chapter-lead-thanks-meet&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/god/2026/110761-ce907886-9202-4a12-a8ce-fad55c5dbcec.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/god/2026/h264-sd/god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4&quot;&gt;god2026-110761-eng-Chapter_Lead_Thanks_meet_you_next_year_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-24T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/dgna/h264-hd/import-110771-deu-Automatisiertes_Fahren_Von_der_Science-Fiction_in_die_Realitaet_hd.mp4">
    <title>Automatisiertes Fahren: Von der Science-Fiction in die Realität (dgna)</title>
    <link>https://cdn.media.ccc.de/events/dgna/h264-hd/import-110771-deu-Automatisiertes_Fahren_Von_der_Science-Fiction_in_die_Realitaet_hd.mp4</link>
    <description>Selbstfahrende Fahrzeuge sind keine Science-Fiction mehr: Seit März 2025 erlaubt die Schweiz als einer der weltweiten Pioniere den fahrerlosen Betrieb auf öffentlichen Strassen. Doch was bedeutet automatisiertes Fahren eigentlich, wie funktioniert es – und wie weit ist die Entwicklung wirklich?

Matthias Rödter (Präsident) und Dirk Apel (Vizepräsident) vom Swiss Transit Lab geben Einblick in das reale Pilotprojekt iamo im Furttal und zeigen, welche Chancen automatisierte Mobilität für die Gesellschaft eröffnet – von neuen Verbindungen bis zu mehr Teilhabe.

Im Zentrum steht dabei auch die digitale Dimension: Teleoperation, Sensorik, Daten und die netzpolitischen Fragen, die mit dem Fahren ohne Fahrer:in auf uns zukommen. Aber wie steht es um die Risiken?


about this event: https://www.digitale-gesellschaft.ch/event/netzpolitischer-abend-zum-thema-automatisiertes-fahren/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Selbstfahrende Fahrzeuge sind keine Science-Fiction mehr: Seit März 2025 erlaubt die Schweiz als einer der weltweiten Pioniere den fahrerlosen Betrieb auf öffentlichen Strassen. Doch was bedeutet automatisiertes Fahren eigentlich, wie funktioniert es – und wie weit ist die Entwicklung wirklich?

Matthias Rödter (Präsident) und Dirk Apel (Vizepräsident) vom Swiss Transit Lab geben Einblick in das reale Pilotprojekt iamo im Furttal und zeigen, welche Chancen automatisierte Mobilität für die Gesellschaft eröffnet – von neuen Verbindungen bis zu mehr Teilhabe.

Im Zentrum steht dabei auch die digitale Dimension: Teleoperation, Sensorik, Daten und die netzpolitischen Fragen, die mit dem Fahren ohne Fahrer:in auf uns zukommen. Aber wie steht es um die Risiken?


about this event: https://www.digitale-gesellschaft.ch/event/netzpolitischer-abend-zum-thema-automatisiertes-fahren/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/dgna-110771-automatisiertes-fahren-von-d&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/dgna/110771-ed3fb2fa-a8b7-4434-8712-7ce6335b13af.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/dgna/h264-hd/import-110771-deu-Automatisiertes_Fahren_Von_der_Science-Fiction_in_die_Realitaet_hd.mp4&quot;&gt;import-110771-deu-Automatisiertes_Fahren_Von_der_Science-Fiction_in_die_Realitaet_hd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-17T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-11-eng-What_Has_Been_Brewing_in_KDE_PIM_Land_sd.mp4">
    <title>What Has Been Brewing in KDE PIM Land? (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-11-eng-What_Has_Been_Brewing_in_KDE_PIM_Land_sd.mp4</link>
    <description>In 2026, the Sovereign Tech Fund commissioned work to bring KDE software closer to readiness for large enterprises and public institutions. As part of this work, KDE PIM infrastructure had to be improved.

In this talk, we will cover the bug fixing and improvements we did around Akonadi resources and their protocol libraries. This will help all the applications using Akonadi to be at the forefront in term of protocol updates.

To get there, we also setup an end-to-end tests suite using Python. We will thus do a detour on how we structured those tests for better test data management and reduced flakiness. It will also show the bugs you can catch this way but not with unit tests.

If your life is stored in an IMAP and a DAV server, if you&#39;d like things to be easier to configure, or if you&#39;d like a better Flatpak experience for KDE PIM applications, then join us and rejoice! We&#39;ll tell you what you can expect to see in the next release.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In 2026, the Sovereign Tech Fund commissioned work to bring KDE software closer to readiness for large enterprises and public institutions. As part of this work, KDE PIM infrastructure had to be improved.

In this talk, we will cover the bug fixing and improvements we did around Akonadi resources and their protocol libraries. This will help all the applications using Akonadi to be at the forefront in term of protocol updates.

To get there, we also setup an end-to-end tests suite using Python. We will thus do a detour on how we structured those tests for better test data management and reduced flakiness. It will also show the bugs you can catch this way but not with unit tests.

If your life is stored in an IMAP and a DAV server, if you&#39;d like things to be easier to configure, or if you&#39;d like a better Flatpak experience for KDE PIM applications, then join us and rejoice! We&#39;ll tell you what you can expect to see in the next release.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-11-what_has_been_brewing_in_kde_pim_land&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/11-14b8447b-667d-550f-9db9-9f4c2d4d73ac.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-11-eng-What_Has_Been_Brewing_in_KDE_PIM_Land_sd.mp4&quot;&gt;kde2026-11-eng-What_Has_Been_Brewing_in_KDE_PIM_Land_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-618-deu-SKAfD_-_Trompetenpunk_aus_Dresden_sd.mp4">
    <title>SKAfD - Trompetenpunk aus Dresden (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-618-deu-SKAfD_-_Trompetenpunk_aus_Dresden_sd.mp4</link>
    <description>Punkrock mit Trompete und Saxophon - und ganz viel Pfeffi!

Gestatten? SKAfD, linksgrünversiffte Punkrock-Band aus Dresden.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/QWUFSV/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Punkrock mit Trompete und Saxophon - und ganz viel Pfeffi!

Gestatten? SKAfD, linksgrünversiffte Punkrock-Band aus Dresden.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/QWUFSV/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-618-skafd-trompetenpunk-aus-dresden&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/618-1a933d09-48fc-5bfe-a1a4-6beb051685a2.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-618-deu-SKAfD_-_Trompetenpunk_aus_Dresden_sd.mp4&quot;&gt;ds26-618-deu-SKAfD_-_Trompetenpunk_aus_Dresden_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-19T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-646-eng-TiXim_-_a_decentralized_supercluster_sd.mp4">
    <title>TiX.im - a decentralized supercluster (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-646-eng-TiXim_-_a_decentralized_supercluster_sd.mp4</link>
    <description>TiX is an decentralized, deterministic, user owned, globally designed workflow engine from the future

TiX.im is a fully decentralized, composable, deterministic, workflow engine DAG for interactive and automated workflows in highly isolated containers.
A nix based framework allows the user to build very complex, multi step workflows spanning any agent, harness, script, build step, ... that can be parametrized in an easy way. Workflows can transition between states and are globally reachable using the iroh network.
A unique combination of multiple decentralized networks, the tix.build system, is the first of its kind that can ensure that each software artifact published in the network has succeeded rigorous supply chain analysis by multiple parties as well as a deterministic build process that was succeeded by multiple parties. By splitting the signature key into multiple parts, in which one part is locked inside the maintainers hardware dongle and the other part is distributed among hundreds of nodes (mpc-2pc), any node in the system can be compromised but a malicious release can be prevented.

Since AI supported software attacks, mutating worms, unicode attack vectors (glass worm), etc  became so sophisticated and fast, a complete new set of attack vectors arose that require novel solutions.
This talk will be an architectural design overview with an live demo of this experimental infrastructure project still built in stealth - for a reason.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/NGNBHS/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      TiX is an decentralized, deterministic, user owned, globally designed workflow engine from the future

TiX.im is a fully decentralized, composable, deterministic, workflow engine DAG for interactive and automated workflows in highly isolated containers.
A nix based framework allows the user to build very complex, multi step workflows spanning any agent, harness, script, build step, ... that can be parametrized in an easy way. Workflows can transition between states and are globally reachable using the iroh network.
A unique combination of multiple decentralized networks, the tix.build system, is the first of its kind that can ensure that each software artifact published in the network has succeeded rigorous supply chain analysis by multiple parties as well as a deterministic build process that was succeeded by multiple parties. By splitting the signature key into multiple parts, in which one part is locked inside the maintainers hardware dongle and the other part is distributed among hundreds of nodes (mpc-2pc), any node in the system can be compromised but a malicious release can be prevented.

Since AI supported software attacks, mutating worms, unicode attack vectors (glass worm), etc  became so sophisticated and fast, a complete new set of attack vectors arose that require novel solutions.
This talk will be an architectural design overview with an live demo of this experimental infrastructure project still built in stealth - for a reason.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/NGNBHS/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-646-tix-im-a-decentralized-supercluster&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/646-f6edc97e-07ba-5003-ad8f-61fb64c41f97.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-646-eng-TiXim_-_a_decentralized_supercluster_sd.mp4&quot;&gt;ds26-646-eng-TiXim_-_a_decentralized_supercluster_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-608-deu-Mit_einem_demokratischen_digitalen_Euro_aus_der_Polykrise_sd.mp4">
    <title>Mit einem demokratischen digitalen Euro aus der Polykrise (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-608-deu-Mit_einem_demokratischen_digitalen_Euro_aus_der_Polykrise_sd.mp4</link>
    <description>Utopie für Datenhoheit, direkte Demokratie &amp; gemeinwohlorientierte Wirtschaft. Big-Tech-mit den eigenen Waffen schlagen.

Eine Utopie für Datenhoheit, direkte Demokratie &amp; gemeinwohlorientierte Wirtschaft. Wie wir Tech-Macht brechen &amp; Gesellschaft neu denken. #CBDC4All

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/ER878L/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Utopie für Datenhoheit, direkte Demokratie &amp; gemeinwohlorientierte Wirtschaft. Big-Tech-mit den eigenen Waffen schlagen.

Eine Utopie für Datenhoheit, direkte Demokratie &amp; gemeinwohlorientierte Wirtschaft. Wie wir Tech-Macht brechen &amp; Gesellschaft neu denken. #CBDC4All

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/ER878L/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-608-mit-einem-demokratischen-digitalen-euro-aus-der-polykrise&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/608-c9625cdf-feca-5822-b9ad-34b9febf6bf3.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-608-deu-Mit_einem_demokratischen_digitalen_Euro_aus_der_Polykrise_sd.mp4&quot;&gt;ds26-608-deu-Mit_einem_demokratischen_digitalen_Euro_aus_der_Polykrise_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-36-eng-License_all_the_files_o_sd.mp4">
    <title>License all the files \o/ (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-36-eng-License_all_the_files_o_sd.mp4</link>
    <description>Find out why it&#39;s important to license all your files from the get-go.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Find out why it&#39;s important to license all your files from the get-go.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-36-license_all_the_files_o&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/36-2d4ec895-976f-518c-ae0f-64f33039771b.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-36-eng-License_all_the_files_o_sd.mp4&quot;&gt;kde2026-36-eng-License_all_the_files_o_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4">
    <title>KDE Goals - An Upward Spiral (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4</link>
    <description>Whenever a KDE Goals cycle comes to an end, it launches us into an upward spiral toward the next. In this panel, we’ll look back at the achievements of the 2024–2026 Goals cycle:

- KDE Needs You
- We Care About Your Input
- Streamlined Application Development Experience

And finally, announcing new goals &amp; champions

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Whenever a KDE Goals cycle comes to an end, it launches us into an upward spiral toward the next. In this panel, we’ll look back at the achievements of the 2024–2026 Goals cycle:

- KDE Needs You
- We Care About Your Input
- Streamlined Application Development Experience

And finally, announcing new goals &amp; champions

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-25-kde_goals_an_upward_spiral&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/25-fcfac6fb-567c-522d-9916-0713803b1c23.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4&quot;&gt;kde2026-25-eng-KDE_Goals_-_An_Upward_Spiral_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-2-eng-How_to_cut_a_tree_sd.mp4">
    <title>How to cut a tree (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-2-eng-How_to_cut_a_tree_sd.mp4</link>
    <description>Trees need regular maintenance to stay healthy and productive.

In this talk we are looking at how to take care of a tree, and what it can teach us about software and community.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Trees need regular maintenance to stay healthy and productive.

In this talk we are looking at how to take care of a tree, and what it can teach us about software and community.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-2-how_to_cut_a_tree&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/2-2b2adf8f-674c-5ca1-aefe-c464c3568bfa.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-2-eng-How_to_cut_a_tree_sd.mp4&quot;&gt;kde2026-2-eng-How_to_cut_a_tree_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4">
    <title>Report of the Working Groups (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4</link>
    <description>In this session the working groups of KDE e.V. will present their work of the past year.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this session the working groups of KDE e.V. will present their work of the past year.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-42-report_of_the_working_groups&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/42-1b38ad59-002d-543c-a72a-f51a63f67383.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4&quot;&gt;kde2026-42-eng-Report_of_the_Working_Groups_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4">
    <title>How we hacked the Bavarian State with an Open Source Open Letter (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4</link>
    <description>In September 2025, a few of us Open Source nerds heard that the Bavarian government wanted to &quot;sneakily&quot; &quot;invest&quot; another billion Euro in Microsoft Cloud, Teams and 365 – without a tender, and before the year ends (Base contract)

I talked to friends, and we created an open letter. Soon we were like ten initiators. We found support among many Bavarian Open Source companies and NGOs, only weeks later &gt; 160 companies and institutions had been signing the letter.

When larger German NGOs like the Gesellschaft für Informatik (Society for Informatics) and the Bund der Steuerzahler (Tax Payers&#39; Association joined, the Bavarian Government could not stay silent any more. Leading up of today, two secretaries and the minister president have engaged in a public blame game. At first they were angry about the unwanted, additional publicity - and publicly said so.

The goal of sneakily accomplishing the deal until end of 2025 failed and it is still not finalized. But now - four weeks before an election, secretaries of state for digital and finance are fighting publicly, accusing each other of &quot;fake news&quot; and are saying silly things.
On camera - and in parliament.

&quot;OSS is too expensive&quot; or &quot;We needed something federated, decentralized and secure, thus we had to go for MS 365&quot; and similar. It&#39;s fun.

What we can learn from this? PR for OSS works, timing is helpful, topics are important and claims like &quot;ONE BILLION!!&quot; are valuable. No one knew Trump, Greenland and Davos would come to help us, but they did and made it hard for the conservative Bavarian government to keep doing what they had always been. And we were a bunch of people that stuck it out.
And it&#39;s so important that we the OSS community learn how to play against the lobbys. We need to apply the &quot;divide and conquer&quot; strategy against the real enemies, not internally.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In September 2025, a few of us Open Source nerds heard that the Bavarian government wanted to &quot;sneakily&quot; &quot;invest&quot; another billion Euro in Microsoft Cloud, Teams and 365 – without a tender, and before the year ends (Base contract)

I talked to friends, and we created an open letter. Soon we were like ten initiators. We found support among many Bavarian Open Source companies and NGOs, only weeks later &gt; 160 companies and institutions had been signing the letter.

When larger German NGOs like the Gesellschaft für Informatik (Society for Informatics) and the Bund der Steuerzahler (Tax Payers&#39; Association joined, the Bavarian Government could not stay silent any more. Leading up of today, two secretaries and the minister president have engaged in a public blame game. At first they were angry about the unwanted, additional publicity - and publicly said so.

The goal of sneakily accomplishing the deal until end of 2025 failed and it is still not finalized. But now - four weeks before an election, secretaries of state for digital and finance are fighting publicly, accusing each other of &quot;fake news&quot; and are saying silly things.
On camera - and in parliament.

&quot;OSS is too expensive&quot; or &quot;We needed something federated, decentralized and secure, thus we had to go for MS 365&quot; and similar. It&#39;s fun.

What we can learn from this? PR for OSS works, timing is helpful, topics are important and claims like &quot;ONE BILLION!!&quot; are valuable. No one knew Trump, Greenland and Davos would come to help us, but they did and made it hard for the conservative Bavarian government to keep doing what they had always been. And we were a bunch of people that stuck it out.
And it&#39;s so important that we the OSS community learn how to play against the lobbys. We need to apply the &quot;divide and conquer&quot; strategy against the real enemies, not internally.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-29-how_we_hacked_the_bavarian_state_with_an_open_source_open_letter&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/29-e457b69c-4282-5dfc-b9e9-ee10d4ea7553.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4&quot;&gt;kde2026-29-eng-How_we_hacked_the_Bavarian_State_with_an_Open_Source_Open_Letter_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-14-eng-StyleKit_-_A_common_QML_API_for_styling_Controls_and_Widgets_sd.mp4">
    <title>StyleKit - A common QML API for styling Controls and Widgets (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-14-eng-StyleKit_-_A_common_QML_API_for_styling_Controls_and_Widgets_sd.mp4</link>
    <description>StyleKit (formerly known under the working title &quot;Unified Style&quot;) is a new QML module shipped with Qt 6.11 under the &quot;Qt.labs.StyleKit&quot; namespace.

StyleKit is a declarative styling system for Qt Quick Controls _and_ Widgets, built on top of Qt Quick Templates. It lets you define a complete visual style for all your controls from a single Style document, including support for themes, state-based styling, and transitions. StyleKit handles the underlying template implementation automatically, letting you focus purely on visual aspects such as colors, dimensions, borders, and shadows.

A key strength of StyleKit is its hierarchical property system: set a property once on a base type like abstractButton, and it automatically applies to all button-like controls. Override it where needed for specific controls or states. Changes to your style are instantly reflected across all controls, ensuring consistency while still allowing fine-grained customization.

This talk will introduce the module, demonstrate how it works, and outline future plans.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      StyleKit (formerly known under the working title &quot;Unified Style&quot;) is a new QML module shipped with Qt 6.11 under the &quot;Qt.labs.StyleKit&quot; namespace.

StyleKit is a declarative styling system for Qt Quick Controls _and_ Widgets, built on top of Qt Quick Templates. It lets you define a complete visual style for all your controls from a single Style document, including support for themes, state-based styling, and transitions. StyleKit handles the underlying template implementation automatically, letting you focus purely on visual aspects such as colors, dimensions, borders, and shadows.

A key strength of StyleKit is its hierarchical property system: set a property once on a base type like abstractButton, and it automatically applies to all button-like controls. Override it where needed for specific controls or states. Changes to your style are instantly reflected across all controls, ensuring consistency while still allowing fine-grained customization.

This talk will introduce the module, demonstrate how it works, and outline future plans.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-14-stylekit_a_common_qml_api_for_styling_controls_and_widgets&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/14-c25d48b8-a2b7-5b1a-a7c1-e10abf79c70c.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-14-eng-StyleKit_-_A_common_QML_API_for_styling_Controls_and_Widgets_sd.mp4&quot;&gt;kde2026-14-eng-StyleKit_-_A_common_QML_API_for_styling_Controls_and_Widgets_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-15-eng-Dolphin_the_beloved_filemanager_past_and_future_sd.mp4">
    <title>Dolphin, the beloved filemanager, past and future (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-15-eng-Dolphin_the_beloved_filemanager_past_and_future_sd.mp4</link>
    <description>Present how dolphin is made accross its libraries usage and plugins, its wide usage, its community involvement, and future work ahead.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Present how dolphin is made accross its libraries usage and plugins, its wide usage, its community involvement, and future work ahead.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-15-dolphin_the_beloved_filemanager_past_and_future&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/15-5e0082d6-ad01-5a76-a3c9-0e2d14703f2a.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-15-eng-Dolphin_the_beloved_filemanager_past_and_future_sd.mp4&quot;&gt;kde2026-15-eng-Dolphin_the_beloved_filemanager_past_and_future_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4">
    <title>KDE goes to the Pyramids (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4</link>
    <description>Eike&#39;s adventure using KDE/Qt/HMI software in the field on an archeological mission for a robotic system!

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Eike&#39;s adventure using KDE/Qt/HMI software in the field on an archeological mission for a robotic system!

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-58-kde_goes_to_the_pyramids&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/58-6b6622a4-cac2-5373-8de1-3e09e0b720c7.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4&quot;&gt;kde2026-58-eng-KDE_goes_to_the_Pyramids_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-59-eng-Sponsors_talks_sd.mp4">
    <title>Sponsor&#39;s talks (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-59-eng-Sponsors_talks_sd.mp4</link>
    <description>https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-59-sponsor_s_talks&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/59-5417180e-356f-5a4a-b9e1-aceb3f3b121f.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-59-eng-Sponsors_talks_sd.mp4&quot;&gt;kde2026-59-eng-Sponsors_talks_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4">
    <title>Packaging KDE on Debian (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4</link>
    <description>What is Debian?
What Debian gives the whole open source community, what is special about Debian? (Cross-compiling, Mulit-Arch, reproducible builds,..)
You uses Debian?
 - Cern
 - Debian in outerspace

Why are a distribution like Debian with &quot;a normal release cycle&quot; is still relevant for KDE? Can KDE Linux replace Debian?

What it is about to package KDE software on Debian?
Who is the current Qt/KDE Maintainer team.

Why does Debian ship that old versions?
Why can&#39;t we just ship master branch?

Speak about what were/are the current challenges regarding packaging KDE software on Debian:

 - loosely coupled Palsma
 - kde pim (ABI)
 - transitions from 4-&gt;5, 5-&gt;6
 - lts support
 - QML dependecy tracking
 - bring patches to Debian stable 
 - bring current version to Debian stable

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      What is Debian?
What Debian gives the whole open source community, what is special about Debian? (Cross-compiling, Mulit-Arch, reproducible builds,..)
You uses Debian?
 - Cern
 - Debian in outerspace

Why are a distribution like Debian with &quot;a normal release cycle&quot; is still relevant for KDE? Can KDE Linux replace Debian?

What it is about to package KDE software on Debian?
Who is the current Qt/KDE Maintainer team.

Why does Debian ship that old versions?
Why can&#39;t we just ship master branch?

Speak about what were/are the current challenges regarding packaging KDE software on Debian:

 - loosely coupled Palsma
 - kde pim (ABI)
 - transitions from 4-&gt;5, 5-&gt;6
 - lts support
 - QML dependecy tracking
 - bring patches to Debian stable 
 - bring current version to Debian stable

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-5-packaging_kde_on_debian&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/5-4a7c586e-9bd7-5650-982d-0c9f69dfa8a4.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4&quot;&gt;kde2026-5-eng-Packaging_KDE_on_Debian_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-735-deu-Aber_hier_Leben_Nein_danke_oder_doch_Wie_wir_der_autoritaeren_Zuspitzung_begegnen_koennen_sd.mp4">
    <title>Aber hier Leben? Nein danke! …oder doch? Wie wir der autoritären Zuspitzung begegnen können. (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-735-deu-Aber_hier_Leben_Nein_danke_oder_doch_Wie_wir_der_autoritaeren_Zuspitzung_begegnen_koennen_sd.mp4</link>
    <description>Wie gehen wir mit den Wahlergebnissen in Sachsen Anhalt um?

Strategien für die demokratische Zivilgesellschaft angesichts einer extrem rechten Landesregierung.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/9RBPJX/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Wie gehen wir mit den Wahlergebnissen in Sachsen Anhalt um?

Strategien für die demokratische Zivilgesellschaft angesichts einer extrem rechten Landesregierung.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/9RBPJX/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-735-aber-hier-leben-nein-danke-oder-doch-wie-wir-der-autoritaren-zuspitzung-begegnen-konnen&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/735-bad0b7a0-b3b9-5de6-abad-1c9f930b216a.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-735-deu-Aber_hier_Leben_Nein_danke_oder_doch_Wie_wir_der_autoritaeren_Zuspitzung_begegnen_koennen_sd.mp4&quot;&gt;ds26-735-deu-Aber_hier_Leben_Nein_danke_oder_doch_Wie_wir_der_autoritaeren_Zuspitzung_begegnen_koennen_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-19T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-733-deu-Russische_Drohnen_zerlegen_fuer_Anfaenger_sd.mp4">
    <title>Russische Drohnen zerlegen für Anfänger (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-733-deu-Russische_Drohnen_zerlegen_fuer_Anfaenger_sd.mp4</link>
    <description>Seit 2022 sammeln, zerlegen und dokumentieren wir russische Kriegstechnik. Wenige sind Experten, der Rest guckt rein und googlet

Russische Kriegstechnik bewegt sich zwischen 1960er Jahre Kram und SciFi. Da ich viel an der Front unterwegs bin, habe ich viel davon gesammelt, reingeguckt und dann Experten und Google gefragt, um weiter zu kommen. Dabei waren Triebwerke von nuklearbestückbaren Crusie Missles, Russlands geheimste &quot;stealth&quot; Drohne und jede menge FPV und Flügeldrohnen. Dies wird kein deep drive für Experten sondern ein Blick in diese Welt aus meiner Perspektive. Nicht alle Rätsel der Hardware wurden bisher gelöst.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/KMDYKT/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Seit 2022 sammeln, zerlegen und dokumentieren wir russische Kriegstechnik. Wenige sind Experten, der Rest guckt rein und googlet

Russische Kriegstechnik bewegt sich zwischen 1960er Jahre Kram und SciFi. Da ich viel an der Front unterwegs bin, habe ich viel davon gesammelt, reingeguckt und dann Experten und Google gefragt, um weiter zu kommen. Dabei waren Triebwerke von nuklearbestückbaren Crusie Missles, Russlands geheimste &quot;stealth&quot; Drohne und jede menge FPV und Flügeldrohnen. Dies wird kein deep drive für Experten sondern ein Blick in diese Welt aus meiner Perspektive. Nicht alle Rätsel der Hardware wurden bisher gelöst.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/KMDYKT/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-733-russische-drohnen-zerlegen-fur-anfanger&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/733-d0793a00-7cc3-526d-9e27-e8eb315a8556.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-733-deu-Russische_Drohnen_zerlegen_fuer_Anfaenger_sd.mp4&quot;&gt;ds26-733-deu-Russische_Drohnen_zerlegen_fuer_Anfaenger_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-19T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-712-deu-Closing_sd.mp4">
    <title>Closing (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-712-deu-Closing_sd.mp4</link>
    <description>Shutdown

Wir werten die Datenspuren kurz aus.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/WSKUWY/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Shutdown

Wir werten die Datenspuren kurz aus.

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/WSKUWY/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-712-closing&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/712-9ba47e8b-2b38-5801-bc4f-ffd667c9b3c3.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-712-deu-Closing_sd.mp4&quot;&gt;ds26-712-deu-Closing_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-637-deu-Wir_haben_unser_Leben_heruntergeladen_Was_Unternehmen_wirklich_ueber_uns_wissen_sd.mp4">
    <title>Wir haben unser Leben heruntergeladen: Was Unternehmen wirklich über uns wissen (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-637-deu-Wir_haben_unser_Leben_heruntergeladen_Was_Unternehmen_wirklich_ueber_uns_wissen_sd.mp4</link>
    <description>Wir präsentieren die besten Fundstücke aus den 6.5 GB, die wir aus Datenschutzanfragen von Firmen über uns bekommen haben.

Das Internet vergisst nie. Das haben wir alle schon mal gehört. Aber was bedeutet das eigentlich? In diesem Vortrag zeigen wir das Chaos, die größten Aha-Momente und die bizarrsten Details, die wir erlebt haben, als wir unser europäisches Recht auf die eigene digitale Vergangenheit eingefordert haben.

Wir haben hunderte Unternehmen nach unseren personenbezogenen Daten befragt: Online-Shops, soziale Netzwerke, Werbefirmen, Krankenkassen, Dating-Plattformen und viele mehr. Wir bekamen alles – von handgeschwärzten PDFs bis hin zu Gigabytes an CSV- und JSON-Daten – und versuchten, daraus unser eigenes Online- und Offline-Leben zu rekonstruieren. Um mit den Datenmengen umzugehen, ließen wir die KI Ordnung ins Chaos bringen. Nur um plötzlich zu realisieren, dass sich daraus eine nahezu komplette Biografie unseres Lebens basteln ließ.

In diesem Talk packen wir all die Datensätze aus, die wir bekommen haben: kleine Online-Shops, mittelgroße Tech-Firmen und die Silicon-Valley-Giganten. Haben wir wirklich noch nie jemanden beim Online-Dating geghostet? Können wir nachvollziehen, wo wir vor zehn Jahren im Urlaub waren? Und wollen wir überhaupt wissen, was unser Suchverlauf über uns verrät? Als Live-Demo lassen wir während des Talks einen Agenten auf unsere eigenen Daten los - denn was kann da schon schiefgehen? Schauen wir gemeinsam, wie viele peinliche Details Firmen jetzt schon über uns alle wissen!

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/CGEAWA/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Wir präsentieren die besten Fundstücke aus den 6.5 GB, die wir aus Datenschutzanfragen von Firmen über uns bekommen haben.

Das Internet vergisst nie. Das haben wir alle schon mal gehört. Aber was bedeutet das eigentlich? In diesem Vortrag zeigen wir das Chaos, die größten Aha-Momente und die bizarrsten Details, die wir erlebt haben, als wir unser europäisches Recht auf die eigene digitale Vergangenheit eingefordert haben.

Wir haben hunderte Unternehmen nach unseren personenbezogenen Daten befragt: Online-Shops, soziale Netzwerke, Werbefirmen, Krankenkassen, Dating-Plattformen und viele mehr. Wir bekamen alles – von handgeschwärzten PDFs bis hin zu Gigabytes an CSV- und JSON-Daten – und versuchten, daraus unser eigenes Online- und Offline-Leben zu rekonstruieren. Um mit den Datenmengen umzugehen, ließen wir die KI Ordnung ins Chaos bringen. Nur um plötzlich zu realisieren, dass sich daraus eine nahezu komplette Biografie unseres Lebens basteln ließ.

In diesem Talk packen wir all die Datensätze aus, die wir bekommen haben: kleine Online-Shops, mittelgroße Tech-Firmen und die Silicon-Valley-Giganten. Haben wir wirklich noch nie jemanden beim Online-Dating geghostet? Können wir nachvollziehen, wo wir vor zehn Jahren im Urlaub waren? Und wollen wir überhaupt wissen, was unser Suchverlauf über uns verrät? Als Live-Demo lassen wir während des Talks einen Agenten auf unsere eigenen Daten los - denn was kann da schon schiefgehen? Schauen wir gemeinsam, wie viele peinliche Details Firmen jetzt schon über uns alle wissen!

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/CGEAWA/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-637-wir-haben-unser-leben-heruntergeladen-was-unternehmen-wirklich-uber-uns-wissen&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/637-e4c44250-6a4c-53f5-b2da-e7eeb1483b88.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-637-deu-Wir_haben_unser_Leben_heruntergeladen_Was_Unternehmen_wirklich_ueber_uns_wissen_sd.mp4&quot;&gt;ds26-637-deu-Wir_haben_unser_Leben_heruntergeladen_Was_Unternehmen_wirklich_ueber_uns_wissen_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-41-eng-Report_of_the_board_sd.mp4">
    <title>Report of the board (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-41-eng-Report_of_the_board_sd.mp4</link>
    <description>In this session the board will report on the activities of KDE e.V. over the past year.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In this session the board will report on the activities of KDE e.V. over the past year.

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-41-report_of_the_board&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/41-9c40d186-ea74-5aed-8013-9457866fc452.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-41-eng-Report_of_the_board_sd.mp4&quot;&gt;kde2026-41-eng-Report_of_the_board_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-689-deu-Build_Europes_Fediverse_Video_Infrastructure_-_Aufbau_1_europaeischen_Fediverse-Videoinfrastruktur_sd.mp4">
    <title>Build Europe&#39;s Fediverse Video Infrastructure (DS2026)</title>
    <link>https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-689-deu-Build_Europes_Fediverse_Video_Infrastructure_-_Aufbau_1_europaeischen_Fediverse-Videoinfrastruktur_sd.mp4</link>
    <description>In dem Talk geht es um den weiteren Aufbau einer europäischen Videostruktur mit Peertube, europäisch, skalierbar und dezentral.

Das Fediverse hat sich in den vergangenen Jahren als glaubwürdige Alternative zu den großen zentralisierten Plattformen etabliert. Millionen Menschen nutzen bereits dezentrale soziale Netzwerke wie Mastodon, PeerTube, Pixelfed oder z.B. Friendica. Gleichzeitig stehen diese Dienste vor einer gemeinsamen Herausforderung: Während die Zahl der Nutzerinnen und Nutzer wächst, fehlen häufig die technischen Grundlagen, um Video-Streaming, Livetranscoding und weitere ressourcenintensive Dienste zuverlässig und wirtschaftlich bereitzustellen.

Der FediHub setzt genau an dieser Stelle an. Ziel ist es nicht, einzelne Plattformen oder Instanzen zu finanzieren, sondern eine gemeinsam nutzbare Infrastruktur aufzubauen, die allen Projekten innerhalb des Fediverse zugutekommt. Die Kampagne versteht Infrastruktur als digitales Gemeingut und lädt Community, Organisationen, Bildungseinrichtungen und Unternehmen dazu ein, dieses Gemeingut gemeinsam aufzubauen und langfristig zu tragen.

Die Kampagne verbindet Crowdfunding, Community-Aufbau, Öffentlichkeitsarbeit, institutionelle Förderungen und strategische Partnerschaften zu einer langfristigen Bewegung. Ihr Ziel ist es, FediHub als zentrale Infrastrukturinitiative für ein unabhängiges und skalierbares Fediverse zu etablieren.

Ich würde gerne unser erstes Projekt von FediHub, PRISM vorstellen wollen und Wesen finden sich sich daran beteiligen möchten.

Mehr Informationen asap, unter . https://fedihub_org.codeberg.page/ &amp; https://fedihub.org/ &amp; https://anoxinon.de/

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/LKYRYJ/
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      In dem Talk geht es um den weiteren Aufbau einer europäischen Videostruktur mit Peertube, europäisch, skalierbar und dezentral.

Das Fediverse hat sich in den vergangenen Jahren als glaubwürdige Alternative zu den großen zentralisierten Plattformen etabliert. Millionen Menschen nutzen bereits dezentrale soziale Netzwerke wie Mastodon, PeerTube, Pixelfed oder z.B. Friendica. Gleichzeitig stehen diese Dienste vor einer gemeinsamen Herausforderung: Während die Zahl der Nutzerinnen und Nutzer wächst, fehlen häufig die technischen Grundlagen, um Video-Streaming, Livetranscoding und weitere ressourcenintensive Dienste zuverlässig und wirtschaftlich bereitzustellen.

Der FediHub setzt genau an dieser Stelle an. Ziel ist es nicht, einzelne Plattformen oder Instanzen zu finanzieren, sondern eine gemeinsam nutzbare Infrastruktur aufzubauen, die allen Projekten innerhalb des Fediverse zugutekommt. Die Kampagne versteht Infrastruktur als digitales Gemeingut und lädt Community, Organisationen, Bildungseinrichtungen und Unternehmen dazu ein, dieses Gemeingut gemeinsam aufzubauen und langfristig zu tragen.

Die Kampagne verbindet Crowdfunding, Community-Aufbau, Öffentlichkeitsarbeit, institutionelle Förderungen und strategische Partnerschaften zu einer langfristigen Bewegung. Ihr Ziel ist es, FediHub als zentrale Infrastrukturinitiative für ein unabhängiges und skalierbares Fediverse zu etablieren.

Ich würde gerne unser erstes Projekt von FediHub, PRISM vorstellen wollen und Wesen finden sich sich daran beteiligen möchten.

Mehr Informationen asap, unter . https://fedihub_org.codeberg.page/ &amp; https://fedihub.org/ &amp; https://anoxinon.de/

Licensed to the public under https://creativecommons.org/licenses/by/4.0/de/
about this event: https://talks.datenspuren.de/ds26/talk/LKYRYJ/
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/ds26-689-build-europe-s-fediverse-video-infrastructure-aufbau-1-europaischen-fediverse-videoinfrastruktur&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/datenspuren/2026/689-2abd733b-d103-526a-bdbe-291d67de4ab1.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/datenspuren/2026/h264-sd/ds26-689-deu-Build_Europes_Fediverse_Video_Infrastructure_-_Aufbau_1_europaeischen_Fediverse-Videoinfrastruktur_sd.mp4&quot;&gt;ds26-689-deu-Build_Europes_Fediverse_Video_Infrastructure_-_Aufbau_1_europaeischen_Fediverse-Videoinfrastruktur_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-19T00:00:00+02:00</dc:date>
  </item>
  <item rdf:about="https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4">
    <title>Akademy Awards, &amp; Closing Announcements (kde2026)</title>
    <link>https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4</link>
    <description>Akademy Awards (10-20 mins)
Closing Announcements - GET TO THE PARTY (5-10 mins)

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
</description>
    <content:encoded>&lt;div align=&quot;center&quot;&gt;
      Akademy Awards (10-20 mins)
Closing Announcements - GET TO THE PARTY (5-10 mins)

https://creativecommons.org/licenses/by-sa/4.0/
about this event: https://c3voc.de
&lt;br/&gt;
    &lt;a href=&quot;https://media.ccc.de/v/kde2026-60-akademy_awards_closing_announcements&quot;&gt;&lt;img src=&quot;https://static.media.ccc.de/media/events/kde/kde2026/60-080a3084-e465-5eca-892e-a052efd60668.jpg&quot; /&gt;&lt;/a&gt;&lt;br/&gt;
    &lt;b&gt;Video:&lt;/b&gt;&lt;a href=&quot;https://cdn.media.ccc.de/events/kde/kde2026/h264-sd/kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4&quot;&gt;kde2026-60-eng-Akademy_Awards_Closing_Announcements_sd.mp4&lt;/a&gt;
&lt;/div&gt;
</content:encoded>
    <dc:date>2026-09-20T00:00:00+02:00</dc:date>
  </item>
</rdf:RDF>