Does "secure" implies some protections against Spectre-like attacks?
A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
41–50 of 68 posts
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#42As 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.
Yes it’s a real shame it isn’t based on object capability security. The resource ID concept makes it really hard to do per-module restrictions, because resources provide global ambient access to anything. And it sounds to me like the dispatch model based on typed arrays means that this is baked in on a fundamental level (unless there are some unforgeable handles that Ryan didn’t mention in his talk).
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#43Does "secure" implies some protections against Spectre-like attacks?
No, it is about how v8 is sandboxed
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#44Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#45> A Secure Runtime for JavaScript and TypeScript So, does it support a specific ECMAscript version? Or am I restricted to the Typescript JS definition? This is confusing..
Nobody's support strictly matches a specific ECMAScript version.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#46Earlier quoted context omitted.
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.
I thought node.js policies were basically just SubResource Integrity hashes? Are they planning for something more?
I’ve been looking into the isolated-vm module recently and it looks pretty nice. Fly.io built their run-untrusted-code service on top of it.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#47Earlier quoted context omitted.
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…
In world of hypervisors, containers, apparmors ..., is sandbox really a significant advantage over nodejs? Actually I saw yt presentation and it didn't convinced me to switch from nodejs. The differences to nodejs are so little, specially when you're using typescript already. The only significant change is "es modules" with ability to resolve modules from url (plus the sandbox). Still big kudos to Ryan for nodejs.
For certain purposes (especially for writing servers), I would actually suggest Go and Rust as much better replacements for Node.js :) (Ryan also mentioned, if you notice, Go as better alternative for fast servers in the original JSConf video)
Ryan and some of us consider the project quite experimental, and the initial focus was not aiming for writing super powerful servers (though it should not be too bad). A pleasant scripting environment with more attention to features that Node have not tried out is more or less the goal.
(Fun fact: Ryan has been into machine learning and data visualization for some time. So Deno was created under the hope to somehow compete with Python in certain aspects)
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#48Earlier quoted context omitted.
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, whi…
It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#49Earlier quoted context omitted.
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, whi…
It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution
Since modules are loaded from URLs, it would be per TLD.
Re: A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio
#50Earlier quoted context omitted.
It is actually more interesting about the definition of “per module”, because technically every single file is its very own module from the view of V8, and is reinforced in Deno since we are trying to be web compatible, so there is not even a package.json-like construct for you to identify the “root” of any library, more so as there is no more index.js magical resolution
Since modules are loaded from URLs, it would be per TLD.
Then how about a site like unpkg.com?
The definition even becomes much more blurry as redirections and other possible protocols are involved.