4 ms·

> 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 reproducibl

> 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/ https://reproducible.archlinux.org/

NekkoDroid 2y ago
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
- hedora 2y ago
  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!
  - NekkoDroid 2y ago
    > 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.

NekkoDroid 2y ago

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

hedora 2y ago
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!
- NekkoDroid 2y ago
  > 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.