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.
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.
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.
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.
That's bonkers. I had no idea.
import safe MyDependency
... but do you have to make sure that nothing in the tree is claiming to be Trustworthy. Which is actually pretty easy.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.
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.
Any others?
[0]: https://discourse.haskell.org/t/deprecating-safe-haskell-or-...
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.
Cannot agree with this oversimplification.
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.