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

please provide similar functionality to scripts and unsafe-inline from Content-Security-Policy #11052

Closed
benatkin opened this issue Jun 19, 2021 · 2 comments

Comments

@benatkin
Copy link

I'm looking into building a Visual Studio Code extension that will let users run Deno scripts to transform code without having to inspect the source, instead just relying on the permission system. The permissions system is great for that. I also want them to be able to inspect it if they need to, and to require the scripts installed to be easy to inspect. This would mean limiting the size of the files, as well as limiting what deps they could pull in. I could start with allowing just the standard library, and like browser extensions providing an additional prompt to add another source.

For actually running the code, deno info --json my-script.ts enables me to check where the code is coming from.

One thing that might be an issue, though, is having unexpected network requests to an unknown URL that could collect the IP address. People have complained about that with Visual Studio Code's support for JSON schemas and they fixed it: microsoft/vscode#96083

If I have a file, there is no easy way to make sure when I run a deno command that it isn't going to pull down from something that isn't on my approved list of places. I'm thinking of showing a list of places that dependencies can come from, along with the source of the script, when installing a script.

If I have a file:

import { test } from "https://analytics.untrustedsite.com/util.ts";

test();

Whether I run deno check --json, deno run, deno install, or deno compile on it, it's going to try loading from "https://analytics.untrustedsite.com/util.ts". I'm thinking I'll read the source. That won't apply to transitive deps, but if the initial deps are trusted that can help.

Furthermore I would like to choose which deno.land/x/ scripts are allowed. This is where the Content-Security-Policy spec wouldn't be quite enough. Perhaps both a Content-Security-Policy and an analog to allow-net that applies to module resolution could be supported.

I found a similar issue but it was closed by the creator of the issue, not a maintainer of Deno.


As I was typing this I found https://deno.land/[email protected]/linking_to_external_code/proxies – this might be the ticket! Still not as easy as it could be.

@bartlomieju
Copy link
Member

Would #8266 help you in any way? (Keep in mind that this flag is meant for import() and Worker())

@benatkin
Copy link
Author

@bartlomieju yeah, that is along the same lines. I will close this issue and link to it from there, and also link to it from the allow-csp issue.

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

2 participants