Ask HN: How much can we trust open-source projects or our hardware?

For large open-source security-focused projects like Kali Linux, we’re told there are no backdoors but with millions of lines of code, how can we actually verify that? Full manual auditing isn’t feasible for most individuals.

Some thoughts/questions:

Are reproducible builds and supply-chain audits enough to trust the binaries?

What strategies exist for spotting subtle backdoors in such large codebases?

For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems (e.g. Intel ME, AMD PSP)?

Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?

Beyond reading every line yourself, what’s the best way to build confidence?

How much trust (percentage-wise) do you personally put in OSS security projects or commodity hardware, and what technical mitigations do you use to minimize blind trust?

3 points | by solosquad 1 day ago

6 comments

benoau 1 day ago
You have to at a minimum trust the OS vendor, probably a slew of development tools, and blindly trust all the hardware you work upon and cloud platforms you deploy to to only-work as advertised.
You shouldn't particularly trust any software, monitor outbound traffic, silo your different projects to minimize what software is adjacent to your projects and the fallout if something got access, minimize programming dependencies and browser and IDE extensions and add-ons and stuff coming from unknown 3rd parties. Stay behind the latest builds/updates/releases so problems have time to be identified.
mikewarot 19 hours ago
Strictly speaking, Linux, no matter what distribution, is insecure by design. Linus Torvalds's choice to ignore the lessons of Minux, and his instructor Andrew S. Tanenbaum resulted in short term gains that have cost us all in the long run.
With a microkernel system, you only have to really trust the kernel, and it's very small. You can build provably secure systems in this manner.
The last commonly available hardware/software combination that you could actually trust was an IBM PC/XT with dual floppy disks running MS-DOS. The write protection was enforced in hardware, so you could make and keep clean copies of the operating system.
pabs3 1 day ago
Reproducible builds aren't enough, you need projects that are reproducibly bootstrappable solely from source without any binaries. Usually the starting point is a small amount (an MBR) of manually entered documented machine code.
https://bootstrappable.org/ https://stagex.tools/
pabs3 1 day ago
Almost all firmware is proprietary, so you aren't going to be able to trust it at all. Try to use hardware that has at least open boot firmware like u-boot or coreboot.
https://wiki.debian.org/Firmware/Open
lordkrandel 1 day ago
Secure for what? Intrusion? Spying? Data collection? Dont use internet then. Disconnect. No data will be taken from your laptop this way, unless you are a secret agent, or a criminal.
bigyabai 1 day ago
Kali Linux is a pentesting distro. It's not claimed to be secure and AFAIK it makes deliberately insecure design decisions to enable spoofing/SDR attacks.
```
  Are reproducible builds and supply-chain audits enough to trust the binaries?
```
No. But for most applications trust isn't really required.
```
  What strategies exist for spotting subtle backdoors in such large codebases?
```
It's not hard. For big projects, contributors are usually a tight-knit group that heavily scrutinize any outsider PRs. By creating a rigorous system of code review (and implementing reminders for bad dependencies) you can deter backdoors decently well.
```
  For hardware, how do you approach the risk of compromised firmware, microcode, or hidden subsystems
```
You cannot.
```
  Do projects like Coreboot, Heads, or formally verified kernels meaningfully reduce this risk in practice?
```
No, but if properly configured they can reduce attack surface as-advertised.
```
  Beyond reading every line yourself, what’s the best way to build confidence?
```
I know this is a dumb answer, but "be smart" will get you a really long ways. Stick to the main roads, don't use software developed by 2 or 3 people if your personal security is paramount. Keep your systems slim and minimally networked, route any home servers through a VPN or proxy to prevent it from being harassed on the open internet.
[-]
- solosquad 1 day ago
  that’s true kali it’s designed for pentesting and not necessarily as a secure daily driver, but I was using it more as a stand-in example for large OSS projects where security is critical. Maybe a better example would be Qubes OS or OpenBSD