4 ms·

What do you expect deno to do? Should it have a "repository" of whitelisted domains? Should it do typo checking for you? What is considered "good security defau

What do you expect deno to do? Should it have a "repository" of whitelisted domains? Should it do typo checking for you? What is considered "good security defaults" here? Deno doesn't intentionally control where and how you import dependencies as long as the code in the dependency is valid and I think that's better than gatekeeping domains. Deno has permissions built-in just for this - i.e., if a dependency goes rogue, there's some level of control. Consider node/bun on the other hand. If a dependency goes rogue, there's virtually nothing stopping it except system permissions. That's a lot worse than deno. I think Deno tries to solve the core issue with running untrusted code (like a browser does to some extent). Dependency control can only go so far. So no complaints here. This also gives Deno flexibility to support package.json with the same exact security guarantees. Isn't that better?

ar-nelson 4y ago
> Should it have a "repository" of whitelisted domains? Yes, actually. Deno's security model allows you to whitelist file paths and network domains with --allow-read, --allow-write, and --allow-net. But this doesn't apply to static imports. I don't see why it needs to be this way. There should at least be a flag or deno.json config option that would require you to explicitly approve every new import domain, which would prevent typo attacks and make long chains of transitive imports obvious. deno.land could be allowed by default.
xg15 4y ago
One option would be to include some hash value in the URL to pin the code file, e.g import ... from 'https://...##<...sha...>'; https://...##<...sha...>'; Then a typo would just result in a resolution error.
- ar-nelson 4y ago
  This could be implemented as an import assertion[1]: import foo from 'http://example.com/foo http://example.com/foo' assert { sha256sum: '...' } This feature would even be useful in the web platform in general. Would also be nice to see an assertion for importing plain text files (not just JSON files) and assertions for per-module Deno permissions. [1]: https://github.com/tc39/proposal-import-assertions https://github.com/tc39/proposal-import-assertions
  - xg15 4y ago
    I think for the web platform, there is already Subresource Integrity [1] which follows the same idea. Unfortunately, it works at the level of script tags, so can't be used inside a script. But maybe this could be a starting ground for making a proposal. [1] https://en.m.wikipedia.org/wiki/Subresource_Integrity https://en.m.wikipedia.org/wiki/Subresource_Integrity

ar-nelson 4y ago

> Should it have a "repository" of whitelisted domains? Yes, actually. Deno's security model allows you to whitelist file paths and network domains with --allow-read, --allow-write, and --allow-net. But this doesn't apply to static imports. I don't see why it needs to be this way. There should at least be a flag or deno.json config option that would require you to explicitly approve every new import domain, which would prevent typo attacks and make long chains of transitive imports obvious. deno.land could be allowed by default.

xg15 4y ago

One option would be to include some hash value in the URL to pin the code file, e.g import ... from 'https://...##<...sha...>'; https://...##<...sha...>'; Then a typo would just result in a resolution error.

ar-nelson 4y ago
This could be implemented as an import assertion[1]: import foo from 'http://example.com/foo http://example.com/foo' assert { sha256sum: '...' } This feature would even be useful in the web platform in general. Would also be nice to see an assertion for importing plain text files (not just JSON files) and assertions for per-module Deno permissions. [1]: https://github.com/tc39/proposal-import-assertions https://github.com/tc39/proposal-import-assertions
- xg15 4y ago
  I think for the web platform, there is already Subresource Integrity [1] which follows the same idea. Unfortunately, it works at the level of script tags, so can't be used inside a script. But maybe this could be a starting ground for making a proposal. [1] https://en.m.wikipedia.org/wiki/Subresource_Integrity https://en.m.wikipedia.org/wiki/Subresource_Integrity