-
Notifications
You must be signed in to change notification settings - Fork 5.4k
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
feat: add --allow-import
flag
#25469
Conversation
Ooops, wrong PR. |
This reverts commit 05a39e9.
…em on the first pass
--allow-imports
flag--allow-import
flag
cli/graph_util.rs
Outdated
// skip type checking when there are any external remote modules | ||
// because those will be surfaced as errors later and would cause | ||
// type checking to crash | ||
graph.modules().any(|module| match module { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems strange to me - do we just silently skip checking and there's no info surfaced about it? Or is it getting surfaced somewhere else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to update this comment. If the graph contains any of these then it's invalid.
// allow remote import permissions in the lsp for now | ||
allow_import: Some(vec![]), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe open an issue about this one and ask @nayeemrmn to add a setting in vscode_deno
to pass an allow list?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please update the PR description to mention that this flag replaces --allow-net
for imports/workers?
Also note to self to update the docs page with new flag.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@bartlomieju , @dsherret , I'm hitting new, unexpected permission requests based on this change. Can "cdn.jsdelivr.net:443" and "cdn.skypack.dev:443" be added to the defaults? |
Probably the defaults will be left as-is. We can't guarantee the security of all hosts. |
@dsherret , thanks for the reply. Just to discuss a bit more... JSDelivr is one of the largest (if not the largest) NPM and GitHub CDNs; SkyPack is more niche but I think similar to ESM.sh in being one of the first on the scene for ESM conversion and hosting. SkyPack seems to be able to generate types for more packages as well. And, at least JSDelivr should be a minimal security issue as it's sponsored the biggies, Cloudflare and Fastly, and delivering more than 250 billion requests monthly (compared to only 450 million per month for esm). Using only "esm.sh" seems like a weird choice, in comparison. Since it looks like this just landed in RC7, I hope you'll look at these and pass them along to the other devs and reconsider adding the two. Thanks for the consideration. |
* Deno-v2.0.0-rc7+ is now requiring "import" permissions - JSDelivr and SkyPack are not on the Deno-2.0 default allowlist - esm.sh *is* included in the "allow-import" default domain list - ref: <denoland/deno#25469> to comply with Deno-2.0 'import' permission defaults
@dsherret , another data point is that some places where using JSDelivr, as a CDN, simply downloads and succeeds, esm.sh is doing some translation and fails. For example, Using |
* Deno-v2.0.0-rc7+ is now requiring "import" permissions - JSDelivr and SkyPack are not on the Deno-2.0 default allowlist - esm.sh *is* included in the "allow-import" default domain list - ref: [Proposal/discussion](denoland/deno#8266) - ref: [Merged solution](denoland/deno#25469)
* Deno-v2.0.0-rc7+ is now requiring "import" permissions - JSDelivr and SkyPack are not on the Deno-2.0 default allowlist - esm.sh *is* included in the "allow-import" default domain list - ref: [Proposal/discussion](denoland/deno#8266) - ref: [Merged solution](denoland/deno#25469)
* Deno-v2.0.0-rc7+ is now requiring "import" permissions - JSDelivr and SkyPack are not on the Deno-2.0 default allowlist - esm.sh *is* included in the "allow-import" default domain list - ref: [Proposal/discussion](denoland/deno#8266) - ref: [Merged solution](denoland/deno#25469)
* Deno-v2.0.0-rc7+ is now requiring "import" permissions - JSDelivr and SkyPack are not on the Deno-2.0 default allowlist - esm.sh *is* included in the "allow-import" default domain list - ref: [Proposal/discussion](denoland/deno#8266) - ref: [Merged solution](denoland/deno#25469)
This replaces
--allow-net
for import permissions and makes the security sandbox stricter by also checking permissions for statically analyzable imports.By default, this has a value of
--allow-import=deno.land:443,jsr.io:443,esm.sh:443,raw.githubusercontent.com:443,gist.githubusercontent.com:443
, but that can be overridden by providing a different set of hosts.Additionally, when no value is provided, import permissions are inferred from the CLI arguments so the following works because
fresh.deno.dev:443
will be added to the list of allowed imports:Closes #8266