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

State of the Web: Deno

byteofdev.com

Post reply on HN
Print view View original

21–30 of 116 posts

Re: State of the Web: Deno

#21

Post by goldsteinq »

keyKeeper wrote: post #20
goldsteinq wrote: post #16

Deno’s permission system is broken, you shouldn’t rely on it. Deno developers consistently ignore security issues, high priority bugs take months to fix. https://github.com/denoland/deno/issues/11964 https://github.com/denoland/deno/issues/9750 API-based access control can’t possibly work because it’s nearly impossible to predict the effect of any single permission. For example, “permission to run specific command” m…

So, If I understand it correctly the security issues are at architectural level and not simply bugs? Is there an alternative tool you can suggest, to allow us securely run arbitrary JS? I was looking at Apple's JavaScriptCore to run JS and and if it happens that I need any level of access to the system(i.e. files) simply handle that in Swift and pass the file to the JS. Would that be a secure approach?

Yep, trying to restrict the access to a system on the API level instead of the OS level will inevitably lead to problems like these (Deno is doing worse than it could though).

If you want to isolate your program, you should use an OS-level sandbox like bubblewrap or a lightweight VM like Firecracker. I’m not familiar with Apple’s JavaScriptCore, but if it doesn’t provide any access to the system (and instead relies on passing arguments from Swift code), it might also be a viable approach.

Re: State of the Web: Deno

#22

Post by greggman3 »

afiori wrote: post #13
dmitriid wrote: post #7

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

there is not really a difference between a url to a registry and a npm package name. the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it

There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.

Re: State of the Web: Deno

#23

Post by keyKeeper »

goldsteinq wrote: post #21
keyKeeper wrote: post #20

Earlier quoted context omitted.

So, If I understand it correctly the security issues are at architectural level and not simply bugs? Is there an alternative tool you can suggest, to allow us securely run arbitrary JS? I was looking at Apple's JavaScriptCore to run JS and and if it happens that I need any level of access to the system(i.e. files) simply handle that in Swift and pass the file to the JS. Would that be a secure approach?

Yep, trying to restrict the access to a system on the API level instead of the OS level will inevitably lead to problems like these (Deno is doing worse than it could though). If you want to isolate your program, you should use an OS-level sandbox like bubblewrap or a lightweight VM like Firecracker. I’m not familiar with Apple’s JavaScriptCore, but if it doesn’t provide any access to the system (and instead relies o…

> if it doesn’t provide any access to the system

Yes, my understanding is that it's the pure language interpreter without anything about filesystems or web browser. You need to create an interface in Swift/Objective-C or C to put in and get data out of the execution context.

Re: State of the Web: Deno

#24

Post by forty »

tmikaeld wrote: post #10
pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;)

Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

Re: State of the Web: Deno

#25

Post by forty »

pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

Exactly. I think whatever actualy good idea deno might come up with will eventually be adopted by nodejs, which will make deno less relevant.

Re: State of the Web: Deno

#26

Post by dmitriid »

afiori wrote: post #13
dmitriid wrote: post #7

Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"

there is not really a difference between a url to a registry and a npm package name. the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it

> there is not really a difference between a url to a registry and a npm package name.

There is. For starters, I can run my company's registry and make sure all npm packages are downloaded from there since resolution mechanism for npm/yarn is well known.

How do I tell deno to download from my own registry?

Looking at how deno "solves" this I can't stop laughing [1]

--- start quote ---

In Deno there is no concept of a package manager as external modules are imported directly into local modules. This raises the question of how to manage remote dependencies without a package manager. In big projects with many dependencies it will become cumbersome and time consuming to update modules if they are all imported individually into individual modules.

The standard practice for solving this problem in Deno is to create a deps.ts file. All required remote dependencies are referenced in this file and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies...

With all dependencies centralized in deps.ts, managing these becomes easier.

--- end quote ---

Are you for real?

[1] https://deno.land/manual/examples/manage_dependencies

Re: State of the Web: Deno

#27

Post by dmitriid »

tmikaeld wrote: post #10
pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

"smaller, faster, purpose-made modules" directly leads to "thousands of dependencies".

Re: State of the Web: Deno

#29

Post by tehbeard »

forty wrote: post #24
tmikaeld wrote: post #10

Earlier quoted context omitted.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

My understanding is that one of the goal of deno is to be more compatible with the Web. As a backend only dev I don't find that great, I rather have clearer separation between quality backend modules and shitty 100-dependencies web modules ;) Also I don't want smaller modules. I want bigger and better maintained modules with few dependencies. Small modules is what makes npm ecosystem not that great.

> quality backend modules and shitty 100-dependencies web modules

As someone who works in both stacks, I have seen incredibly shitty backend modules that dump 400mb of node_module deps.

I'd even argue node ecosystem is at fault because frontend adopted their package manager and "best practices".

So off of your high horse.

And Deno's goal of web compatible is in using web APIs where applicable instead of special snowflakes ( eg the web crypto api as browsers use vs nodes crypto module) and being permission focused rather than access by default. Feel free to debate the merits of that instead.

Re: State of the Web: Deno

#30

Post by pjmlp »

tmikaeld wrote: post #10
pjmlp wrote: post #9

Deno is an interesting experiment, but I don't see it ever replacing nodejs, beyond the nodejs ecosystem eventually adopting it. It is the usual case of worse is better, and nodejs for better or worse, does it job.

I beg to differ, Deno adds some fire to quality modules becoming the better norm for javascript on the server-side, smaller, faster, purpose-made modules and frameworks that don't rely on thousands of dependencies. Of course, it's up to each and every developer that contribute, but looking at some of the most up-stared Deno modules, that's the direction it's heading.

My relevant stars are what IT decides to install on devenvs or is part of RFPs technical requirements.
Post reply on HN