Package Managers need global hooks

The only major blemish in Debian's record was in 2006 when one of its developers patched OpenSSL to avoid using uninitialised memory as a source of randomness, in order to placate a static analyser. Nobody in Debian noticed that this effectively made OpenSSL key generation entirely predictable (it only generated one of 32768 unique keys), for 2 years.

2. Codegen is extremely common (serialisation, reflection, bindings, etc.) to the extent that even requiring a whitelist of packages that can do code-gen seems like a non-starter (because everyone will just whitelist everything). Sandboxing build-time execution seems like a more practical approach than denying it.

3. It's not clear to me that this distinction is meaningful for many package managers. Crates.io for example distributes a packaged set of sources. What are you comparing these against? There's no requirement that the original sources be hosted anywhere public, and I definitely don't think it should be mandating use of GitHub or anything.

4. Needs to be a whitelist rather than mandatory, but yes.

5. Yes, with the caveat below.

6. What do you mean by "locked"? You cannot lock transitive dependencies and still have a usable package infrastructure. If I have packages A and B that both depend on C, then it's critical that the version of C used is maximally flexible, otherwise it becomes impossible for downstream packages to find a version of A and B that are inter-compatible.

In my experience there's a danger for security experts to neglect the practical consequences of the limitations they enforce. This is because they incorrectly place security as the most important requirement, when by definition it cannot be:

Without a product, there is nothing to secure. When a policy becomes too onerous, people don't simply stop doing their work, they work around it. It's a mistake to judge a security policy on what it prevents: a security policy should be judged on what it allows, because an unused or bypassed security policy is less effective than a weak one.

This is why I think thinks like sandboxed execution far more effective than trying to blanket deny things: it enables people to work in a more secure way rather than pushing them towards less secure alternatives. It's why the best way to get people to use secure cryptographic libraries is not just to berate them for doing things themselves, it's to build secure libraries that they want to use because they work well and are ergonomic.

Arch does exactly what Debian for the official repos. It was only the AUR that was compromised. Possibly the issue is that Arch is a bit to strict for the official repos which has forced too many people on to the AUR ones.

There are actually very few techniques that are 99.999% effective. Cryptography when considered per se maybe is, but the wide topic of heuristic analysis is much lesser than that. Even if we consider some imagined, mythical 99.999% effectiveness, it's always measured in the specific boundaries we set during our analysis. Permission rights in the OS are 100% secure if we assume the authentication for sysop is secure. If we store the password for root in a public git repo, then OS permissions are 0% effective even if the system code hasn't changed at all. Your percent value is very fragile and relative to the boundaries we set. The unbreakable wall you think of can turn into a sheet of paper in the blink of an eye.

The cheap port-changing trick can even be 100% effective against generic massive port scanning attacks. But it's 0% effective against a targeted attack. It depends entirely on the surface area we want to defend against. If we define our protection to work against generic automated bots, then changing the port is an entirely effective solution. If we want to ensure our systems are globally "unbreakable" (whatever that means), then it's a weak security solution. In other words, effectiveness is not absolute; it's relative to the threat model.

It's not possible to inspect all the code we use. There's too much of it changing every second. The idea that developers have the time or ability to manually inspect every line of open-source code they import is an economic fantasy. In an era where frontier AI models like Mythos are finding and chaining 0-days in minutes, human review is simply outpaced. But even if we somehow did it, something would already change by the time you finish reading this paragraph. Everything needs to be reanalyzed because we don't know what shifted. And sometimes, the vulnerability manifests in the parts of the code that DIDN'T change.

By the way, I think you might not be aware that current, "next-gen" security solutions offered by Crowdstrike or SentinelOne are actually old antivirus techniques marketed as something new. EDRs are 'just' log aggregators and routers for signatures to be matched on.

Also, please don't think about programmers as someone immune to attacks, as this is not true at all. The fact that programmers invented a method of installation for programmer tools based on piping curl output directly to bash is direct proof that some programmers have absolutely no idea how security works. Especially web developers. If anything, programmers can be more dangerous than normal users because they assume they are better, and then they make the exact same mistakes as everyone else. They are just plain computer users who need to be defended from their own carelessness.

I don't think the issue is Arch is to strict though. I think the issue is Arch isn't good at helping people getting things that should be official to official. Publishing a AUR is easy, getting something from an AUR to official is hard and most people give up - often without trying.