Hacker News Reader

Comment by woodruffw | Hacker News Reader

Defense in depth is the “meat and potatoes” of security.

In other words: people should be auditing their software, but we should also design systems and schemes that provide varying degrees of defense and protection when people invariably fail to review the code they run.

View on HN

Defence in depth is not just 'throw anything in that might improve security' though. The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed. A stronger layer might be sandboxing, or separating your build and publishing steps as others have suggested (and also probably worth restricting the credentials the publishing step to just the relevant packages as well). These will at least robustly prevent a malicious dependency from spreading horizontally, but you'll still potentially ship malware to your customers.

>The idea is to have multiple strong layers, not a hundred half-measures that are all easily bypassed

Definitely. On the other hand, in my opinion, "not running arbitrary code during package install" is not a "half-measure", it's a basic sanity. This whole arbitrary code execution at install time is a convenience feature that was adapted by some package managers, but it was never a good idea.

Fortunately, nixos solves that for me in most cases.

doesn't nixos still have execution hooks when you actually activate a package to use it? Arguably it's just separating the download and install steps (which I do agree, every package manager should have a 'safely download this package so I can inspect it' function as well as a 'make this package ready to use' function, whatever you call those operations. I think 'pip download', for example, managed to violate that expectation which is not particularly sensible)

I would consider 2FA and signing to be strong layers, when applied well. I think everybody agrees we shouldn’t add layers just for the sake of it.

Reply on news.ycombinator.com