3 ms·
If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require`
by mhio 5y ago
If you don't trust the scripts, you don't trust the code. Although this limits one attack vector, the issue is just kicked down the road to `import`/`require` time.
- dane-pgp 5y agoIt does reduce the attack surface a little, though. For example, if you install a package A which depends on B for some obscure feature, and B gets compromised, but you never use A in a way that imports/requires the code in B, then you can potentially dodge that landmine. Similarly, if you are downloading npm packages that provide frontend-only code, that is only run in the context of the browser's sandbox, then you don't have to worry about arbitrary code execution (although a malicious frontend package could still exfiltrate user passwords, among other things).
- mhio 5y agoYeah it's definitely an improvement, but there needs to be something more. The way dependencies move depending on when you run a yarn/npm install has never been useful. Both for projects initialising a lock, and projects upgrading from a previous locked position.