I assume you compile the source code because you want to be sure you don't use any compromised binaries? But how can you be sure the source code wasn't compromised with some obfuscated C code? (Honest question, I'm just a humble application developer.)

While I do not build LFS regularly or for production use, the security improvement typically comes from the fact that the end system is _super_small_ and focused. Less software means less attack surface.

Sure, compromised binaries are nasty but personally I do place quite a lot of trust with the distribution repos.

(PS, if you are reading this and contribute packages to distribution repos: Thank you!)

You can never be 100% sure. Even the compiler, firmware, or hardware could be compromised.

Security comes down to reducing attack surface, ideally to an infinitesimal degree.

It is dramatically easier to hide malware in a compiled artifact than in public source code, not to imply that the latter does not happen.

In security focused orgs though you review all code yourself with the exception of things with extensive third party signed review such as the Linux kernel itself. Even then I review codepaths in the kernel critical for my use case such as random.c

From there, if I -alone- compile containers, kernels, or binaries, someone could coerce me to tamper with them to compromise all downstream users. Same if there was a central build system I can access. To mitigate this I ensure my artifact builds are deterministic, sign my changes, and have team members review my changes, reproduce my artifacts bit for bit, then counter-sign the results.

It is never wise to be in a position where there is possibility of you yourself tampering with things that control anything of value, or else someone will coerce you to help them steal said value.

As a security engineer it is my job to ensure no one ever has to trust anyone, including me.

Typo in your homepage: "Continuious Integration"

Interesting thread!

Good catch!

As in manually or https://buildroot.org/ ?

I used to make heavy use of buildroot but these days for most of my use cases I just have a kernel, and an init/application binary that I statically compile into the kernel. A simple makefile gets the job done and is easier to review than the whole of buildroot.

what happens if the program crashes? with no init there is no way to restart it?

> And yeah, threadrippers are a must.

I mean, they give a wonderfully higher quality of life for compiling but they are $2,500-6,000 just for the CPU. Of course this can be done on much lower-cost CPUs! A 12-core Ryzen is already at the "I have lots of money to spend" end of what I'd suggest for something like this.

If you are compiling Linux kernels for a living, odds are near 100% your time waiting on compiles costs more than an employer buying you a beefy CPU.

Sorry, by "something like this" I meant LFS. Obviously the word "this" was ambiguous as GP said "I compile linux kernels for work".