the current fragility of the "software supply chain" stems from package managers and their perverse economic incentives, and this is just as true for "pure languages". Vendoring and auditing dependencies greatly reduces the attack surface area.
Can you elaborate on the incentives of package managers? The problem I see with Rust is that it's just really easy to add dependebcies in a way that is difficult in C++.
I don't follow your point about purity. A dependency in a side-effect free language can't suddenly open a socket or access the file system. The attack surface is much smaller.
Rust : Cargo :: Haskell : Hackage . It's extremely easy to add dependencies and that problem is independent of purity.
As an example of an "impure language" with security in the form you envision, Deno allows you to specify access controls on a per-script or per-dependency basis. You can specify imports that prevent dependencies from opening sockets or writing files or reading files.
Many years ago npm inc treated download and package counts as KPI. They pushed back against sensible measures like code signing, instead centralizing the ecosystem and encouraging cross-dependencies within their registry. A more security-oriented package manager would have focused on code signing and vendoring strategies.
Haskell is largely pure. There's nothing in place to stop a dependency from putting unsafePerformIO on blast. If a dependency can only do pure functional computation then the worst things it can do are like (1+1=4) or diverge.
From your description it sounds like Deno is using object capabilities -- that's a great step forward.
> Many years ago npm inc treated download and package counts as KPI.
I believe GP misspoke; to my knowledge Deno does not allow you to set permissions on dependencies. It's not using object capabilities as far as I'm aware. I wish it were!
> A dependency in a side-effect free language can't suddenly open a socket or access the file system.
A dependency can exploit your system deliberately, not just with side effects. If you're not strictly pinning all of your dependency versions, one malicious update that makes it to the package manager can ruin your whole world.
Our package managers operate entirely on trust. Nobody is guaranteed to be checking to make sure some random package's maintainer isn't submitting malicious updates.
As a community we're all lazy and basically hope that somebody else is invested enough to check everyone else's work. In the case of OpenSSL, we've found that some projects become so complex that almost nobody does for long periods of time.
I think the thing that makes it more tractable in pure languages is that you at least get the chance to control the dependency's inputs and inspect all of its outputs, so it's theoretically possible to limit what it can do to you (depending on how you are using those outputs). I'm not saying it's usually practical, but it's at least conceivable. And there should be at least a few cases where it's actually practical.
In an impure language, it can do any random thing to any random part of the whole system and you won't even get the chance to know what it is doing.
Are there any truly pure package management systems out there, though?
Haskell has Safe Haskell, which more or less guarantees that the actual Haskell code compiled through the normal path is pure (but not that the code is total, and total under resource constraints, which you also need). The build system itself is not pure, though, so you have no guarantee that a dependency's build scripts don't put Evil Things into your program outside of the actual language framework.
I think you're using "side effects" in a colloquial sense while I'm using it in a PL sense.
Pure code is deterministic, operating only on its params. Impure code—code with side effects—is something that depends on state outside of its parameters.
Exists community. Yes, every human have his own motives, but many live in countries with effective law enforcement, and many people obey Western Values.
Also important, software is a chain with many parts, some parts of one chain could make really large disruptions, some are less significant.
So overall, real formula includes trust, humanity values, laws, government effectiveness and inertia of this chain.