Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

External module tampering protection? #170

Closed
ejsmith opened this issue Jun 6, 2018 · 8 comments
Closed

External module tampering protection? #170

ejsmith opened this issue Jun 6, 2018 · 8 comments

Comments

@ejsmith
Copy link

ejsmith commented Jun 6, 2018

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?

@musab
Copy link

musab commented Jun 6, 2018

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

@ejsmith
Copy link
Author

ejsmith commented Jun 6, 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?

@bhouston
Copy link

bhouston commented Jun 6, 2018

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.

@Janpot
Copy link

Janpot commented Jun 7, 2018

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.

@nmabhinandan
Copy link

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.

@Macil
Copy link

Macil commented Jun 8, 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.

@Janpot
Copy link

Janpot commented Jun 9, 2018

@agentme From the project description:

Aims to be browser compatible.

And the browser addressed this issue with subresource integrity. a Mechanism like that can find a parallel in deno easily.

@ry
Copy link
Member

ry commented Aug 7, 2018

closed in favor of #200

@ry ry closed this as completed Aug 7, 2018
piscisaureus pushed a commit to piscisaureus/deno that referenced this issue Oct 7, 2019
@kitsonk kitsonk mentioned this issue Jun 13, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants