You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
Whether I run
deno check --json
,deno run
,deno install
, ordeno 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.
The text was updated successfully, but these errors were encountered: