Arch Linux and Valve Collaboration(lists.archlinux.org)
lists.archlinux.org
Arch Linux and Valve Collaboration
https://lists.archlinux.org/archives/list/[email protected]/thread/RIZSKIBDSLY4S5J2E2STNP5DH4XZGJMR/
22 comments
[deleted]
I really hope Arch moves to a model like Debian where all packages are built by a central build server. The current strategy—having dozens of different developers compile stuff on their laptops, sign it personally, and then upload the binary blob—leaves a bit to be desired for obvious reasons.
As a novice Arch user, I never realized this is why I needed to update keys often
That's exactly what's happening.
If builds are reproducible, what's the issue?
> If the builds are reproducible, what’s the issue?
Because they’re not! Many packages (including the kernel itself, python, gcc, et al.), are not reproducible. See https://reproducible.archlinux.org/
Because they’re not! Many packages (including the kernel itself, python, gcc, et al.), are not reproducible. See https://reproducible.archlinux.org/
The Kernel isn't reproducible due to modules being signed with a temporary key that gets created and discarded during build. This is to allow loading those modules when secure boot is enabled, without the user needing to sign each and everyone themselves
That sounds like a design gone horribly wrong.
Why not have the package maintainer build once (with all the modules that arch distributes), sign the output with temporary keys, and then add the signatures to the package source?
If the build is reproducible, the signatures will match the output of future builds.
If the user wants to use a custom kernel module, they’ll need to either rebuild with a new key, or turn off safe boot.
That’s vastly preferable than opening the entire kernel to build infrastructure attacks!
Why not have the package maintainer build once (with all the modules that arch distributes), sign the output with temporary keys, and then add the signatures to the package source?
If the build is reproducible, the signatures will match the output of future builds.
If the user wants to use a custom kernel module, they’ll need to either rebuild with a new key, or turn off safe boot.
That’s vastly preferable than opening the entire kernel to build infrastructure attacks!
> If the build is reproducible, the signatures will match the output of future builds.
Anything that contains traces of a private key is not reproducible. The public key needs to be embedded in the kernel to be able to load the signed modules. If you distribute them without signature you can't load them due to the kernel not trusting them, if you sign them in any way with a private key they aren't reproducable since you don't want to hand out the private key. And to prevent additional random stuff being signed with the private key it gets discarded.
> If the user wants to use a custom kernel module, they’ll need to either rebuild with a new key, or turn off safe boot.
Or you can just sign the additional modules (e.g. DKMS) with the same key you sign the kernel & bootloader that you need to enroll into the UEFI anyway. It is less work on the users end and if the distro themselves wanna enable secure boot without user intervention via shim they need to do the signing stuff anyway.
Anything that contains traces of a private key is not reproducible. The public key needs to be embedded in the kernel to be able to load the signed modules. If you distribute them without signature you can't load them due to the kernel not trusting them, if you sign them in any way with a private key they aren't reproducable since you don't want to hand out the private key. And to prevent additional random stuff being signed with the private key it gets discarded.
> If the user wants to use a custom kernel module, they’ll need to either rebuild with a new key, or turn off safe boot.
Or you can just sign the additional modules (e.g. DKMS) with the same key you sign the kernel & bootloader that you need to enroll into the UEFI anyway. It is less work on the users end and if the distro themselves wanna enable secure boot without user intervention via shim they need to do the signing stuff anyway.
It's incredible how, as a privately owned company, Valve avoids the profit chasing short termism of the publically traded companies.
>secure signing enclave
wonder what this involves? TPM stuff?
wonder what this involves? TPM stuff?
Partially. David Runge held a talk about the Secure Signing enclave at All-Systems-Go.
https://media.ccc.de/v/all-systems-go-2024-263-boring-infras...
https://media.ccc.de/v/all-systems-go-2024-263-boring-infras...
Usually, at that level, an HSM (Hatdware Security Module (ex: https://www.entrust.com/products/hsm), but also a fair number of processes and procedures around things like private key generation, key attestation, key verification, certificate renewals, etc etc etc).
There are some parallels with a TPM, but also a great deal of divergence (more so than in common, really).
There are some parallels with a TPM, but also a great deal of divergence (more so than in common, really).
I hope a stable branch may result.
Arch already has a stable branch. If you mean a branch which doesn’t update packages and where "maintainers" pretend they back port "essential" fixes by randomly patching what they ship, I hope it never happens because it would mean Arch is truly dead.
I mean whatever Valve is doing with their biweekly-ish updates becomes available for non Deck users, as a proper branch or whatever you want to call it.
Stability is attained by never updating.
But if you don't update Arch for long enough you will have to install it from scratch in case you want to install anything new.
I learned this by putting Arch on a laptop I barely use.
I learned this by putting Arch on a laptop I barely use.
Valve doesn't stream updates but have a bi-weekly-ish schedule. Plus some guarantee that you can always update from any 'release' to the latest. Decks disappear into drawers for months at a time after all.
This is actually all that Arch needs to have something called a stable branch, and I would love to roll that out to my fleet.
This is actually all that Arch needs to have something called a stable branch, and I would love to roll that out to my fleet.
> This is actually all that Arch needs to have something called a stable branch
I don't think you understand how the Deck handles packaging. You cannot install most pacman or AUR packages on the Deck - root is locked by design and the main way you ingest packages is through filesystem overlays. This works great for centralized update models like the Deck relies on, and forcing users to adopt Flatpak avoids the dynamic linking breakage you would get otherwise. For games, this is excellent. For desktop/developer use, this is unusable.
You should check out NixOS for an Arch-like system with an emphasis on stability and huge package repos. Unlike Arch, NixOS is designed from the ground-up to operate on a read-only filesystem, while providing both declarative (configuration.nix) and iterative package (nix profile install) installation options. There are also read-only verions of other OSes like Bazzite and Kinoite, but Nix is the only one that really feels like Arch with more stability.
I don't think you understand how the Deck handles packaging. You cannot install most pacman or AUR packages on the Deck - root is locked by design and the main way you ingest packages is through filesystem overlays. This works great for centralized update models like the Deck relies on, and forcing users to adopt Flatpak avoids the dynamic linking breakage you would get otherwise. For games, this is excellent. For desktop/developer use, this is unusable.
You should check out NixOS for an Arch-like system with an emphasis on stability and huge package repos. Unlike Arch, NixOS is designed from the ground-up to operate on a read-only filesystem, while providing both declarative (configuration.nix) and iterative package (nix profile install) installation options. There are also read-only verions of other OSes like Bazzite and Kinoite, but Nix is the only one that really feels like Arch with more stability.
But that is precisely what I want for desktop use (which is unlike developer use, for which there already is Arch as-is)!
It sounds like Valve is investing in the security of Arch Linux's build infrastructure to prevent supply chain attacks.