4 ms·
If dependencies are imports from URLs, how does one audit their dependencies? If a server gets hacked those TS can be replaced with malicious versions. In npm
by Osiris 6y ago
If dependencies are imports from URLs, how does one audit their dependencies?
If a server gets hacked those TS can be replaced with malicious versions.
In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release.
Does demo generate some type of file that keeps a hash of all downloaded imports to verify against the next time those imports are downloaded?
- tlrobinson 6y agoIntegrity checking & lock files https://deno.land/manual@v1.9.0/linking_to_external_code/integrity_checking https://deno.land/manual@v1.9.0/linking_to_external_code/int... The same problem (and solution: package-lock.json or yarn.lock) exists in npm if you use semver version specifiers, or npm itself could be hacked, it’s just a bit more acute in Deno since it’s easy and common to load files from arbitrary hosts that don’t enforce immutable versions.
- nikisweeting 6y agonpm has a lot more to lose from being hacked than some random URL, I trust npm with my packages because they fix stuff when something like left-pad happens, the same is not true for every URL I'd have to import to build a deno package.
- dkdbejwi383 6y ago> In npm we at least know that a package is immutable once published, someone could publish a malicious version as a newer release but a current release. This is only true as long as you trust NPM. If they were hacked or taken over by a malicious actor, packages could be modified unbeknownst to you.
- felixfbecker 6y agoNo they could not. Because your package-lock.json contains integrity hashes that are verified during installation.
- Soremwar 6y agoOnly if you update dependencies, a fresh install would not have such integrity checks, so it's just as vulnerable as Deno hosts to such attacks