top | item 20373430

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

428 points| GutenYe | 6 years ago |deno.land

66 comments

order

kevinkassimo|6 years ago

As 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...)

kreetx|6 years ago

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?

codewithcheese|6 years ago

fyi the sound gets much better at the 3 minute mark

LunaSea|6 years ago

As 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.

kevinkassimo|6 years ago

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.

fanf2|6 years ago

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).

qaq|6 years ago

It's not even 1.0 yet.

tfolbrecht|6 years ago

For the inevitably "what differentiates this from node?"

Single executable Allows imports from url File system & network Sandboxing is controlled with flags Dies on uncaught errors

https://deno.land/manual.html#introduction

carlmr|6 years ago

>Dies on uncaught errors

how can JS programmers deal with this?

lajawfe|6 years ago

Watch 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.

pvg|6 years ago

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?

29athrowaway|6 years ago

> 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"

xtreak29|6 years ago

Ryan Dahl, creator of node.js started this project and is also a lead contributor.

dlbucci|6 years ago

Is this a new site, or did the project recently reach a milestone, or is this just resurfacing?

I'm really excited about this project, especially the first-class TypeScript. Could easily see it replacing node for me!

anaphor|6 years ago

What makes this different from something like https://github.com/Agoric/SES ?

inglor|6 years ago

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 :]

qaq|6 years ago

It is being actively developed. Has a large pool of active contributors.

kodablah|6 years ago

I admittedly haven't researched too deeply, but are there any examples/docs on embedding Deno in another Rust program and/or writing/exposing Rust libs with a TS API?

siempreb|6 years ago

> 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..

JeremyBanks|6 years ago

Nobody's support strictly matches a specific ECMAScript version.

ComodoHacker|6 years ago

Does "secure" implies some protections against Spectre-like attacks?

fanf2|6 years ago

No, it is about how v8 is sandboxed

snek|6 years ago

V8 provides some protections against spectre-like attacks, but that's not specific to deno, as Node.js uses V8 as well.

"Secure" in this case refers to being able to not give deno access to the network or filesystem.

unictek|6 years ago

Careful with Deno, performance is still low: https://user-images.githubusercontent.com/3397140/48649635-8...

inglor|6 years ago

That's just FUD through a synthetic benchmark by the person who wrote uWS after he approached Ryan and Ryan wouldn't do everything he asked for...

PudgePacket|6 years ago

That bench has deno at 0.2, it's now at 0.10, though I have no idea how much performance work has been done.

Performance should improve over time, there's no fundamental reason from what I understand that it shouldn't be as fast or faster than node.

node has had 10 years of work and performance effort from so many people and organisations.