>If the programs developer sells out and puts malware into their official binary releases, and the package maintainer doesn't notice this, then checking hashes doesn't protect you from the malicious release.

Nothing short of a full code review will save you from a malicious supply chain attack. This is currently exploding with NPM as well, so building from source doesn't save you here either. See the node-ipc debacle from a few weeks ago [0], and also my own post from last week about a malware infected NPM module [1].

The reality is that yes, the days of being able to trust anything downloaded from a stranger on the internet are pretty much over now. But known-hash package management is still a good first layer of security versus downloading random binaries from the web.

[0] https://nvd.nist.gov/vuln/detail/CVE-2022-23812

[1] https://qqrl.tk/item?id=30963600

> Nothing short of a full code review will save you from a malicious supply chain attack.

Nonsense. Or, at least, an oversimplication.

https://medium.com/agoric/pola-would-have-prevented-the-even...

Nothing short of full code review will ensure that malicious code from a dependency doesn’t get into your program at all, but the capabilities of that malicious code once it does get into your program can certainly be limited.

I don't disagree that Javascript in general runs with a lot more permissions than should probably be given but permissions is a very hard thing to manage. So you decide to install a node package that helps retry and automatically back off requests you want to send to your server since you're working in a mobile environment that has sketchy internet reliability... it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server. Additionally, these permissions will be more comprehensible to review but they still need to be reviewed and reviewed by a party you trust.

That's a tall order for the open source community when it comes to a volume of packages like npm or composer.

You can logically look at lpad as a package and say "We're padding strings, we don't need to do anything with network traffic or disk reads" but building an automated system to make that evaluation and saving that evaluation in a tamperproof manner is going to be hard... and what happens if lpad starts trying to do a better job - operating correctly in left-to-right character sets and in languages where alignment is dictated by hyphens instead of blank space.

Code isn't simple and while the above statement may seem hyperbolic I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk but actually fully 100% preventing that risk? You'll need to check every usage scenario on every set of hardware and go through that code with a fine toothed comb.

> it is very hard to craft a set of permissions to allow that package to retry requests to certain addresses you'd like to retry without also letting it throw random system metrics it's collecting to an ad-server

If you're expecting to have to craft ACLs program-wide for that package, then sure, that's going to be hard. That's more coarse-grained than what I'm talking about here though.

Imagine, if you will, a programming environment where modules you load don't have any authority to access the network, filesystem, etc unless you pass them in. They're just not in scope. In such a language, the default way to grant HTTP access might look like this in pseudo-Python:

  http = require("http")
  myMaliciousLibrary = require("myMaliciousLibrary", http=http)

Now, this library has the problem you mentioned; it can make arbitrary outgoing HTTP requests, meaning it can send any metrics it collects to an ad server. It can't access the filesystem because the filesystem isn't in scope either, so what it can collect is limited, but still more access than it needs. So here's one way you might fix that (obviously highly simplified/incomplete in its implementation):

  class ProxyHTTP(origin="https://example.com", http):
      def __init__(origin="https://example.com"):
          self.allowed_origin = origin
  
      def get(origin, path="/"):
          return http.get(self.allowed_origin, path)
  
  http = require("http")
  myMaliciousLibrary = require("myMaliciousLibrary", http=ProxyHTTP(origin="https://good-site.example.com", http))

Now, this version of myMaliciousLibrary gets an object that looks like the http library it would normally use; it just happens to ignore the origin parameter that the library passes to it and uses the one it was initialized with instead. Now, that library can make requests to good-site.example.com, but if it tries to make a request to adserver.evil.com, it'll go to good-site.example.com instead. (You might also imagine a version of ProxyHTTP that just throws an error if the request's origin isn't the same one it was initialized with, or isn't in a list it was initialized with.)

Most of today's programming languages aren't strict enough to enable this of course; JavaScript isn't there yet for example, and most other languages aren't even close to being able to do this. But that's mostly because they don't provide strict enough encapsulation, not because they're lacking some complex security enforcement mechanism.

> I think it's just because most of us accept the risk, it's highly unlikely that malicious supply chain attacks will suddenly sink our businesses so we accept a reasonable level of security in exchange for what feels like a modest risk

I just think people are accepting way more risk than they realize, given the number of dependencies in modern applications and the amount of access each of those dependencies have. It feels crazy that any one of those dependencies in any application could exfiltrate massive amounts of sensitive data from any machine it happens to run on.

I think there'd be a lot of reliance on all these fundamental components working correctly (and prohibiting other components i.e. "We're using this curl library at a basic level and exposing a safe interface through this protected library but somehow blocking calls from code outside the library") which might have serious repercussions for code reuse.

There are ways you can instruct an OS to block calls to certain library functions/memory ranges (i.e. remove and grant elevations privileges) but I think such a system would need to be designed from the ground up. If you can still `require(lib/reallyOldCurl)` then your protections might allow linters to be able to mark packages as unsafe, but I think it'd be extremely difficult to block access without an extremely fundamental design intent.

I appreciate your reply quite a bit though as I was envisioning the restrictions being defined on a universal package level (aka lpad is given no disk access) rather than being delegated to the consuming developer.

I appreciate what you are saying, but it was over decades ago!

Node is just insane, always was, along with the curl | bash crowd.

Madness.