I feel like the article misses the point, tho. The xz attack didn't happen because of an unsafe language, but for it's legacy build tools and social engineering

I feel like the article misses the point, tho. The xz attack didn't happen because of an unsafe language, but for it's legacy build tools and social engineering. The relevant backdoor part about patching a vulnerability into C code, could just as well have been skipped/changed for another form of persistence/RCE. In the end, the original sin of breach was smuggling and execution of the malicious build script and payload, if I understand correctly. I don't see how a capability sensitive language would have prevented this, assuming the build environment remained the same. Of course certain features of a language are exploited, but for a supply chain attack, I think the real vulnerability is complexity, neglect, carelessness, social pressure and (arcane) code beyond immediate comprehension. Since, before any malicious xz code was shipped, the human element was manipulated and exploited. The same pull request about the introduction of IFUNC, could have been about extending capabilities for another made-up reason. The same exploitation of trust, which allowed packing malicious scripts, would have allowed for... well, packing malicious scripts. With the xz backdoor, the vulnerability was large chunks of infrastructure being the burden of a single human. I really don't see how this attack dynamic could have been prevented by language design alone. Sure, you wouldn't attack a compression library, if capabilities were tight. You would attack the neglected privileged code base elsewhere...