6 ms·

These half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushin

by csomar 2mo ago

These half-measures is why everything has gone to shits. Instead of properly auditing software, reducing the quantity and increasing the quality, we keep pushing more and more garbage where all you find is 2FA that, captcha this, not supported this, app not signed, etc..

woodruffw 2mo ago
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.
- rcxdude 2mo ago
  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.
  - woodruffw 2mo ago
    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.
  - msm_ 2mo ago
    >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.
    - rcxdude 2mo ago
      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)
radku 2mo ago
Can't agree more. I'm working on OSS security tool that can protect you from Shai-hulud, no half measures. The idea is to have a local proxy that injects real secrets into requests in-flight, so a compromised library has nothing to steal because it never had access to any of your secrets: https://github.com/inflightsec/agent-vault-proxy https://github.com/inflightsec/agent-vault-proxy

by csomar 2mo ago

woodruffw 2mo ago

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.

rcxdude 2mo ago
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.
- woodruffw 2mo ago
  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.
- msm_ 2mo ago
  >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.
  - rcxdude 2mo ago
    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)

radku 2mo ago

Can't agree more. I'm working on OSS security tool that can protect you from Shai-hulud, no half measures. The idea is to have a local proxy that injects real secrets into requests in-flight, so a compromised library has nothing to steal because it never had access to any of your secrets: https://github.com/inflightsec/agent-vault-proxy https://github.com/inflightsec/agent-vault-proxy