Deno: External module tampering protection?

Created on 6 Jun 2018 · 8Comments · Source: denoland/deno

This project looks very promising and exciting. I like how simple it is to use external packages. My question would be how would you go about ensuring that external dependencies haven't been changed?

Source

ejsmith

Most helpful comment

I think that one solution is to use github.com/gitlab.com/bitbucket.com references with hashes rather than version numbers. The issue is that will lead to bitrot as github/gitlab/bitbucket projects will churn. I worry that you may need to have a global caching service that deno-cache.com that you can use as a primary point that caches based on hash/version and it ensures you are always alive.

The only thing worse that relying upon npm to be up while building is relying upon many websites to be up while building.

bhouston on 6 Jun 2018

👍4

All 8 comments

Remote URLs are fetched and cached indefinitely on the first load.
Only if the --reload flag is provided will the resource be fetched again.

See http://tinyclouds.org/jsconf2018.pdf

musab on 6 Jun 2018

So the app would be tested with a specific set of code in the cache folder and then packaged up in Docker or whatever other means with that cache folder pre-populated and would always use the same code since it wouldn't be run with the --reload option?

ejsmith on 6 Jun 2018

The only thing worse that relying upon npm to be up while building is relying upon many websites to be up while building.

bhouston on 6 Jun 2018

👍4

how would you go about ensuring that external dependencies haven't been changed?

@ejsmith If you can rule out mitm attacks (https) and you trust the origin to have immutable urls, I don't see how this is less secure than using npm. Because these are two things you trusted npm with in the first place too.

Janpot on 7 Jun 2018

The vendor directory must be in project root by default and .gitignoring it should be discouraged. It's pretty much similar to how Go does it.

nmabhinandan on 7 Jun 2018

and you trust the origin to have immutable urls, I don't see how this is less secure than using npm. Because these are two things you trusted npm with in the first place too.

NPM addressed that issue with the auto-generated package-lock.json, which includes the hashes of the downloaded dependencies. If npmjs.com later tampered with the module, then npm install would see that the downloaded file didn't match the hash in package-lock.json and fail.