One step further, every software you didn't compile yourself and checked the source could have a secret trigger to do harm.

And you need to trust the compiler.

You trust that CPU doing the build? Have you heard about the mess Intel Management Engine is?

Unless you build from the transistors up you have incoherent security theater.

hold on, which universe did you source your matter from?

Here's a tutorial if you want to actually do this, although it's worth pointing out that quality is heavily dependent on how much you're willing to shell out for equipment: https://www.youtube.com/watch?v=s1MCi7FliVY

Nothing old silicon and analog peripherals can't solve.

Indeed, in the end it all comes down to trust. One of my favourite HN comments of all time is this one:

https://news.ycombinator.com/item?id=33899478

If you want to be 'really' secure, you can trust noone. No silicon, no software, no compilers, no certificates, no power grids, no networks, no friends, no coworkers, no nothing.

But that is no life I'd want to live. So I pick my battles and make sure my SecOps is better than 99.9% of the people out there. For me that suffices. YMMV.

> Unless you can validate the worthiness and authenticity of an update

That's the job of traditional Linux distros.

> or sandbox it sufficiently

That does nothing when it comes to E2EE.

> That's the job of traditional Linux distros.

I share this view, but I also think it's very difficult to verify such validation is happening. I don't think most end users would want a distro stable enough to meet a high review bar.

> That does nothing when it comes to E2EE

Not all components need access to the keys or user data. Reducing attack surface reduces the amount that needs to be validated.

Now AI shows just how much malware is in our package managers: https://twitter.com/engageusersai/status/1672872723486310400...

If it works out that the first party has to ship a harmful release to everyone and they can only supply that release through a second party in source code form then we are way ahead of the case where there is only one party. A conspiracy involving multiple entities is much harder to get away with than a unilateral action.

Currently, following the latest updates are a Sophie's choice. Because if your software is a month old, it may have one or two known vulnerabilities, which may or may not be disclosed, may or may not have a POC, and may or may not be actively exploited in the wild. But if you download and install the latest update, then you may receive mitigations for known exploits, but now you very likely have an unknown number of new zero-day vulnerabilities.

So update decisions could have a calculus like, "it's already working; I don't need any feature updates; I'll stick with the stable version" and then attempting to evaluate each CVE on its merits vs. the mitigations offered in each update. (Of course, the way developers like KeePassXC are fighting with the NVD shows that CVE descriptions can't even be trusted these days.)

I foolishly disabled automatic updates for my consumer-grade WiFi router, and I didn't have a plan for manual updates, so it got pwned. I read a few CVEs and I'm fairly sure I know how it was pwned remotely. Thankfully it didn't seem to be making lateral moves into my computing devices, or acting against me personally, and I was able to disinfect the router and put it back into service. The vulnerabilities that enabled the pwnage were fixed by an update which was released about a month before the pwnage, so if I'd been on automatic updates, I probably would've been safe. And that's what the hackers count on.

I'm sorry this makes absolutely no sense to me. It feels like a convoluted explanation for being stubborn about auto updates and then an example of precisely why they're useful.

I would take an unaudited patched-for-known-cves over just not updating any day.