> Valve is generously providing backing for two
critical projects that will have a huge impact on our distribution: a
build service infrastructure and a secure signing enclave.
It sounds like Valve is investing in the security of Arch Linux's build infrastructure to prevent supply chain attacks.
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.
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
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.
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).
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.
> Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave.
It sounds like Valve is investing in the security of Arch Linux's build infrastructure to prevent supply chain attacks.
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/
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!
> 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.
>secure signing enclave
wonder what this involves? TPM stuff?
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).
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...
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.
Stability is attained by never updating.