A Secure Runtime for JavaScript and TypeScript Built with V8, Rust, and Tokio

Post by pvg » Sun, Jul 07, 2019, 6:08 PM UTC

ricardobeat wrote: post #57

pvg wrote: post #20

Earlier quoted context omitted.

It is very interesting although I didn't really understand the 'security' part. The motivation seems to be twofold - some bad things have happened because of compromised npm packages and v8 happens to have a robust sandbox. This sounds like a solution looking for a vaguely defined problem. The illustrative example he gives is 'malicious linter'. Is malicious linter that important a threat?

In the example the linter itself is not malicious, but used to deliver a malicious program that can have unrestricted filesystem access. Not vague at all, see recent news on the ‘event-stream’ package being used to steal cryptocurrency wallets.

Post by z3t4 » Sun, Jul 07, 2019, 7:11 PM UTC

kevinkassimo wrote: post #48

LunaSea wrote: post #30

Earlier 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

Post by carlmr » Sun, Jul 07, 2019, 11:45 PM UTC

novaleaf wrote: post #56

carlmr wrote: post #38

Earlier quoted context omitted.

It was rhetorical and meant to be facetious.

on node, this can actually be very difficult or even impossible if using 3rd party libraries. For example, some node internals like networking require the invoker to attach to some obscure .on("error") event to avoid uncaught errors. and a lot of the time these 3rd parties are not aware of it. I'm all for deno being built from the ground up to properly crash on uncaught errors. Silent ignoring is a really stupid deci…

Post by novaleaf » Mon, Jul 08, 2019, 5:28 AM UTC

spion wrote: post #58

novaleaf wrote: post #56

Earlier quoted context omitted.

on node, this can actually be very difficult or even impossible if using 3rd party libraries. For example, some node internals like networking require the invoker to attach to some obscure .on("error") event to avoid uncaught errors. and a lot of the time these 3rd parties are not aware of it. I'm all for deno being built from the ground up to properly crash on uncaught errors. Silent ignoring is a really stupid deci…

I never understood why this is necessary. Using promises means you get to use try-with-resources style construct for handling non-memory resources safely. As such you no longer need to crash on uncaught errors, except errors pertaining to resource disposal.