Would be nice also to have the V8 implementation in Rust as well.
Instead I would rather a SpiderMonkey written in Rust.
A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
21–30 of 68 posts
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#22As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up flipping all security switches off because your application needs every feature (network, filesystem, etc). No package signing, no flags per module, no syscall whitelisting, etc.
It's not even 1.0 yet.
I'm not talking about the maturity of the project but more about the concept of the feature flag for security.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#23As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up flipping all security switches off because your application needs every feature (network, filesystem, etc). No package signing, no flags per module, no syscall whitelisting, etc.
You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox.
(For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect atm)
We have also discussed about possibilities of implementing an in-memory file system. (Maybe we will also bring sessionStorage to Deno)
Flags per module is slightly trickier, while whitelisting of certain feature is trivial to implement.
Package signing is indeed a topic that Deno contributors need to discuss further and possibly finding a solution.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#24Earlier quoted context omitted.
> Access between V8 (unprivileged) and Rust (privileged) is only done via serialized messages defined in this flatbuffer. Expect to see this in "n things I regret about deno"
Can you explain why?
Every deno API function call goes through flatbuffer serialization + deserialization + more steps. Sounds like a lot of overhead.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#25Watch 10 things I regret about node. js - https://youtu.be/M3BM9TB-8yA from the creator of both node and deno to undersatnd his motivations behind the deno project. A very intriguing talk.
> Access between V8 (unprivileged) and Rust (privileged) is only done via serialized messages defined in this flatbuffer. Expect to see this in "n things I regret about deno"
Replying to Flatbuffers concerns:
You are right, we will try to get rid of it for some faster serialization mechanisms (after some huge internal refactor lands). See the talk I posted, Ryan mentioned about it near the end.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#26As a contributor to Deno, I am actually quite surprised that this got resurfaced on Hacker news after the hype June last year. That being said, I suggest checking out this video (recorded this April) for updated information about Deno, since things have changed quite a bit since the initial announcement: https://youtu.be/z6JRlx5NC9E (Edit: fixed link, posted the wrong one. Why would YouTube think I want to share ads.…
Curious about deno's development stage: can the brave already run it in production, or there are probably too many breaking changes in the pipe that it's better to wait?
The brave? Sure - but there will likely be breaking changes. I actually run a small deno server in production for a non critical service and it's been working out fine :]
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#27What makes this different from something like https://github.com/Agoric/SES ?
SES builds on capability theory to let you run "adversarial" code together with your trusted code safely.
Deno is a runtime that aims to isolate the code from the system amongst other issues.
SES uses a proof over the JS grammar with induction, Deno does isolation by not giving any OS level access to your code.
Neither are particularly complete and are mostly orthogonal. Both are looking for people to help with them :]
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#28Earlier quoted context omitted.
It's not even 1.0 yet.
I'm not talking about the maturity of the project but more about the concept of the feature flag for security.
Node.js had a PR to add that in (with packages enforced but not your 'own' code) and Node has policies to deal with loading untrusted code ( https://nodejs.org/api/policy.html ).
Personally I isolate with OS level containers as I think it's a lot more robust and tested but I definitely see the merit in Deno exploring this - even if it doesn't really work yet it's interesting.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#29Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#30As a long time Node.js developer I took a look at the project but it's still a really half-baked implementation of the security flags. You almost always end up flipping all security switches off because your application needs every feature (network, filesystem, etc). No package signing, no flags per module, no syscall whitelisting, etc.
You turn all permissions on if you are actually using it as if it is Node for writing servers. But in the case when you are using a (potentially untrusted) code snippet to perform certain operations (like encode/decode base64 values), you do might want a sandbox. (For the case of Node-like usage, we actually also have a basic implementation of whitelisted directories/files for certain permissions, though not perfect…
Sure but logic doesn't exist in a vacuum so in most cases you are going to import / export your input data or your results to the filesystem or through the network.
I actually suggested a more granular, per-module approach to this during the Node Forward and IO.js debacle years ago: https://github.com/node-forward/discussions/issues/14
At the time it was deemed to difficult to implement in Node.js after the fact, which makes sense of course. But I'm disappointed that Deno didn't go for a more bolder, more secure approach. The current system seems pretty pointless.