[c7b]

After the npm supply chain attacks people suggested automating delays before installing updates, now we're talking about automating update delivery... I'm afraid there won't be any easy or quick fix after decades of treating security as an afterthought.

[ordu]

Linux distros are not npm. It doesn't mean they are infallible to malicious actors, but I believe it is possible to make them infallible for some small set of packages at least.

Attacks are still possible, but if we look at xz backdoor attack[1] it was insanely complicated attack and it still failed. Its fail doesn't look promising, attack could succeed just the attacker was unlucky. Still it shows that the success is not guaranteed.

Theoretically npm can be improved in this way, if there were a separate "distro" for packaged, with dedicated maintainers for packages, who don't write code, just pull it from a mainstream and review it. It is not being done because of tragedy of commons, not because it is impossible.

[1] https://en.wikipedia.org/wiki/XZ_Utils_backdoor

[c7b]

Linux itself, major Linux distros, npm - none of these were designed with a security-first approach. Even the things that do help with security, like package maintenance or containerization, were more incidental to other primary goals like stability, reproducibility and so on rather than being born from a comprehensive security-first strategy. They could have been, but then things would have moved slower. They even exist, like Alpine, OpenBSD, RedoxOS, but the major ones, the ones we're talking about today, were the ones who moved faster and managed to take over. That's the fundamental issue I'm talking about, the mindset shift that would be required before we could even start the Herculean effort of rebuilding much of the existing stack with different architectures, in different languages and using different development models, always knowing that, in the past, the ones who moved fast and broke things instead tended to be the ones who succeeded.

[ordu]

I technically agree, but it seems too abstract to me. How could look a distro maintenance, if it was built with a security-first approach?

Maybe I have not enough fantasy and/or creativity, but trying to imagine it, I see just a bit more of oversight built into protocols of approving changes to repositories. I mean, it doesn't seem that improved security needs an approach "destroy everything and build it from scratch", some additions on top of existing structures would do. Am I wrong?

[c7b]

If we were to start from security first, we would be asking questions like 'how can we make sure that new code is safe?'. Manual review is great, but we can likely think of some desirable invariants for program behavior that could be tested automatically, or even formally verified. Those would come at the very start. The entire mindset right now is that the existing code is probably unsafe and we'll ship fixes as we discover its vulnerabilities. Not immediately applying updates is seen as a kind of moral failure. All major OS and most software projects were developed with this mindset of crossing your fingers at launch and then changing the tires while driving. So much so that we think of it as the natural state of software. If you start from a base of verified code, the mindset shifts. Not that there are zero vulnerabilities guaranteed in the existing code, but you become a lot more suspicious of new code.

[ahartmetz]

Whenever you read about an incredibly unlucky criminal, there's a chance that the unlucky event is a parallel construction to the classified real reason why they were caught. Not sure how exactly that would have worked in this case.

[ordu]

Yes, it could be. But it is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?

Are you arguing that the system may be more resilient than it seems? Like, maybe there is a conspiracy working on security. And they keep themselves secret so attackers would be susceptible to under-appreciate the real level of security and make mistakes that inevitable would caught?

It seems like a over-stretched explanation, doesn't it. Care to explain yourself?

[ahartmetz]

I mentioned it mainly because I find it interesting. We are probably just slightly less lucky than it seems. This particular case doesn't look that much like a parallel construction to me.

[akimbostrawman]

>is a hypothetical that smells like a conspiracy theory. I wonder why you think it is a good idea to go for these hypotheticals?

Its always amusing to me when people use "conspiracy theory", a word deliberately popularized and weaponized by said agencies (CIA Memo 1035-960) to mock people for doubting and asking questions about there supposed operations and tactics.