sure it is. how could deno maintain its security model and implement all of the node apis? part of why it works is because there's a standard lib and there's no way to obscure usage and thus circumvent the permissions. unless your answer is that --allow-run is the solution. even with the OP post, they don't even support child_process with deno deploy, which is why, but clearly they can't support everything and still maintain security, which is the point.
consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?
Bartek from the Deno team here, let me clarify a few things.
> for one the security model is incompatible with node APIs.
All Node.js APIs are polyfilled using Deno APIs and as such these Node.js API are subject to the same permission model as regular Deno programs.
> however if deno were to support all npm packages, it would necessarily basically have to implement the entire node api, including support for pre async/await (aka callbacks)
We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based.
> consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?
This is the same situation as with Deno's FFI API. You need to pass `--allow-ffi` flag to enable usage of `Deno.dlopen` (or `require("./foo.node")` for N-API extensions). That said when you load dynamic libraries all bets are off - we can't control what the dynamic library can do and you effectively open up your whole system. Still, you can't load such libraries unless `--allow-ffi` flag is passed.
> We're not aiming for 100% compatibility, though we managed to polyfill a hefty amount of built-in Node modules, including ones that are callback based.
yeah, I'm aware of this. my point was that you couldn't 100% compatibility without compromising. fwiw it's a good thing. node can be a security nightmare if your team is not disciplined about dependencies.
w.r.t to node apis, technically you are like you say polyfilling them. and with that implementation differences hopefully allow you to continue to polyfill.
sure it is. how could deno maintain its security model and implement all of the node apis? part of why it works is because there's a standard lib and there's no way to obscure usage and thus circumvent the permissions. unless your answer is that --allow-run is the solution. even with the OP post, they don't even support child_process with deno deploy, which is why, but clearly they can't support everything and still maintain security, which is the point.
consider just the c++ embedder apis. how exactly would deno deal with that with respect to permissions?