Open legoktm opened 1 year ago
@legoktm Headbutting into this for a quick note:
Unfortunately there is no easy way to protect non-repro builds, especially if using external infrastructure. We abhor CI for our kernel builds for that reason.
But there is a suggestion, which applies to repro builds:
If the builds are reproducible, then anybody can basically verify them in your team.
You could also deploy a data diode (if available to you or you trust someone to be capable enough to build one) to automate the retrieval of the signatures/checksums.
Secure CI is very much an unsolved problem, for now.
As for non repro builds: they would arguably be the most secure, but you give up the seed/structure randomization capabilities of the grsec patch. However, this is also the case for public/published kernel packages: you are already giving up the structures/ABI of the vmlinux and co. Any compile-time mitigations that affect system unpredictability are mutually exclusive with providing external access to the kernel binaries.
Splitting from https://github.com/freedomofpress/securedrop/issues/6514
On a technical level, to build packages one needs a machine (currently a clean Qubes VM) that has Docker installed, and then:
make securedrop-core-5.15
, wait 2+ hoursmake securedrop-workstation-5.15
, wait 2+ hoursCurrently these steps are done manually, on maintainer laptops. This seems ripe for automation, especially because it's a slow process.
One important note is that these builds are currently not reproducible (see #3).
So if we were to automate this process, what are the requirements for the build host? Would we be OK if:
Pinging @l3th3 & @lsd-cat for security input