Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Deno.js in production

medium.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Deno.js in production

#51

Post by mostlylurks »

danenania wrote: post #7

The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…

I, too, would like to have per-dependency security policies. But I can't really see where you would realistically draw the line between dependencies, other dependencies, and your own code. Is a callback, created in your own code, that potentially accesses dangerous APIs allowed? Presumably yes, but what about when it is passed to a dependency that proceeds to call it? What if the dependency returns the callback back to your own code, can you call it then? What if the dependency wrapped the callback in another callback that calls the original callback with altered arguments, and returns that to your code? Do you enforce any potential restrictions statically, necessitating much stricter restrictions on what you can do than typescript on its own does, or at runtime, necessitating some sort of non-trivial bookkeeping tracking all the parts of the codebase that any piece of behavior has touched?

Re: Deno.js in production

#52

Post by gorjusborg »

winrid wrote: post #5
BeefWellington wrote: post #4

It is disappointing to see this message as the basics of what the software is on their site ( https://deno.land/ ): Deno is a simple, modern and secure runtime for JavaScript, TypeScript, and WebAssembly that uses V8 and is built in Rust. Only to have that immediately followed by really poor practice of suggesting this as the installation method: curl -fsSL https://deno.land/install.sh | sh This is not strictly relat…

It's using SSL, what's the real world concern here? Other than someone might get copy-paste happy and someday install something they don't want.

https://www.idontplaydarts.com/2016/04/detecting-curl-pipe-b...

Re: Deno.js in production

#53

Post by duxup »

3np wrote: post #2

> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)

I've tried Deno. The author might rethink that line after interviewing me.

Really though this seems almost like resume keyword checking level of a candidate quality check. Actually it sounds exactly like that...

Re: Deno.js in production

#54

Post by [deleted] »

krautsourced wrote: post #24
unwind wrote: post #21

> ‘Deno’ (like ‘Node’ but backwards) Yeah, no. I wonder if more people just assume that to be true, heh. I kind of was expecting it, weirdly enough. Hint: "node" is "edon" backwards. Not sure if that name is taken for something Javascripty ... * goes to check * yeah, I found [1] which seems to be 4 years old, tagline "Run browser JS in the terminal". [1] https://github.com/dbkaplun/edon

Deno is No|de swapped. So no, not backwards. But... how would one call it?

[deleted]

Re: Deno.js in production

#55

Post by [deleted] »

krautsourced wrote: post #24
unwind wrote: post #21

> ‘Deno’ (like ‘Node’ but backwards) Yeah, no. I wonder if more people just assume that to be true, heh. I kind of was expecting it, weirdly enough. Hint: "node" is "edon" backwards. Not sure if that name is taken for something Javascripty ... * goes to check * yeah, I found [1] which seems to be 4 years old, tagline "Run browser JS in the terminal". [1] https://github.com/dbkaplun/edon

Deno is No|de swapped. So no, not backwards. But... how would one call it?

[deleted]

Re: Deno.js in production

#56

Post by danenania »

mostlylurks wrote: post #51
danenania wrote: post #7

The security model is a big one for me. If they could extend the permissions system to work for individual dependencies, they could solve one of the biggest security issues facing developers right now. Especially if policies could also be applied to node packages. Are there any plans to move in this direction? It seems like if you can do it for the full app, you should hypothetically have the capability to make it li…

I, too, would like to have per-dependency security policies. But I can't really see where you would realistically draw the line between dependencies, other dependencies, and your own code. Is a callback, created in your own code, that potentially accesses dangerous APIs allowed? Presumably yes, but what about when it is passed to a dependency that proceeds to call it? What if the dependency returns the callback back…

While I don't have the answers to all these questions, I imagine we could come up with some sane defaults.

Even if you have to 'eject' and provide overly broad permissions to certain libraries, I'd imagine these would be quite a small percentage and you'd still get the huge win that the 90% (or whatever) of your dependencies that don't need any system or network access at all and don't have the kind of issues you describe can effectively be removed as viable targets for attack.

For callbacks, Deno could provide a wrapper function that is only available to the top-level app (not dependencies) and causes the permissions in the callback to be evaluated at the app level, not the dependency level. There may be a better way, but that's one idea.

Static checking would be great too. I think a combination of static and runtime enforcement would be ideal.

Re: Deno.js in production

#57

Post by rootlocus »

krautsourced wrote: post #24
unwind wrote: post #21

> ‘Deno’ (like ‘Node’ but backwards) Yeah, no. I wonder if more people just assume that to be true, heh. I kind of was expecting it, weirdly enough. Hint: "node" is "edon" backwards. Not sure if that name is taken for something Javascripty ... * goes to check * yeah, I found [1] which seems to be 4 years old, tagline "Run browser JS in the terminal". [1] https://github.com/dbkaplun/edon

Deno is No|de swapped. So no, not backwards. But... how would one call it?

little-endian

Re: Deno.js in production

#58

Post by skybrian »

danenania wrote: post #16
BeefWellington wrote: post #10

Earlier quoted context omitted.

How do you guarantee that their install script is non-malicous and was actually provided by them? There's a reason why code signing exists as a security measure.

While signing does improve security, it's still something of a turtles-all-the-way-down problem because how do you verify the public key is valid? An additional factor is added, which helps, but it's not a silver bullet. And the complexity tradeoffs of requiring cross-platform installation of a signing lib like gpg/minisign (which plenty won't already have installed) and a much larger install snippet are significant.

For the Mac at least, signed dmg files and apps are normal, so they should have done it that way.

Re: Deno.js in production

#59

Post by 14u2c »

3np wrote: post #2

> Node.js is too easy to get started. This means that the pool of available programmers is not the highest quality. Runtimes like Go or Deno are still havens for the ‘connoisseur’ programmer. wat (Deno seems worth checking out though!)

Yea, this is one of the most garbage takes I've ever heard. Requiring the use of something esoteric is not suddenly going to allow you access to a pool of higher quality candidates. Instead you will still see the same pool, but now the average candidate will be even less knowledgeable about the technology.

I do like Deno personally, but this reason is not a great one to do so.

Re: Deno.js in production

#60

Post by danenania »

zdragnar wrote: post #29
danenania wrote: post #20

Earlier quoted context omitted.

Why is that? I may be missing something, but they're already enforcing permissions at runtime, which seems like the hard part to me. It would 'just' need to be integrated with the call stack so you know which dependency(ies) want system/network access.

IIRC there are all sorts of issues around monkey-patching prototypes, shared objects between modules, etc. which would readily allow escaping any sort of module / dependency level permissions system. You'd probably be better off pitching a typescript subset language with its own compiler / interpreter rather than trying to shoehorn it into V8.

These seem like solvable problems. Prototype modifications are rare these days and should probably be restricted in the same way that system/network access is. Shared objects between modules also seem like an edge case apart from callbacks? I posted an idea on how to handle callbacks upthread a bit: https://news.ycombinator.com/item?id=31326123#31332061
Post reply on HN