41–50 of 116 posts
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"
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…
> deno run --allow-read=./assets
That said, I think one should still be wary of running random code - but at least deno makes it a little easier for honest authors to adhere to principle of least privilege?
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.
What is "shitty"? Do we have something better than that? Like one big web framework which is both maintainable, DCE-able and solved everything frontend ever needs? Why further modularization of this theoretical module would be shitty?
Edit: Also, what are we comparing to? VS202x takes several gigabytes for a base set of libraries. Xcode is tens of gigabytes now, afaik. Qt is few gigabytes. Enterprise systems also take few gigabytes at least. But when node_modules takes more than 80mb to produce a 0.5mb bundle for a webscale product, we start to complain. I don't understand.
Earlier quoted context omitted.
Re: the first linked issue, does it only affect scripts that require the --allow-run permission in some form? Are the other permission types (--allow-read/write/net/etc) also affect by this or similar issues somehow? The 2nd issue does seem concerning to have taken so long to resolve.
Yes, it exploits `--allow-run=whatever` + `--allow-write=whatever` to execute arbitrary code outside of the sandbox. The problem with the Deno security model is that it’s hard to predict how granting any specific permission would affect overall security. For example, it may seem to be kinda reasonable for an application to ask for `--allow-write=~/.config` to create config directories & files, but it’s probably explo…
It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions.
Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect.
Today with Node any random package can download any DLL as long as it is novel enough to pass antivirus (hint: last I checked a 17 year old could make a trojan that flew straight past, no questions asked.)
Even Node is usable with the right precautions.
But trying to get people away from thinking about Deno is not ok.
Why is it that ES6 modules load only asyncly but Node.js CommonJS modules only syncly? I find sync is often simpler to code for.
Because the ESM standard specifies that modules are loaded by URL and themselves might initialize async. Once anything is async the whole call stack into it is. See also various discussions of “colored functions” which have made the rounds again recently.
// main.js
const fs = require("fs")
const foo = await require_async("foo")
await foo.sleep(1000)
// other.js
require("./main.js")
// RequireError: main.js returned an unsettled promise, use require_async()
Earlier quoted context omitted.
Yes, it exploits `--allow-run=whatever` + `--allow-write=whatever` to execute arbitrary code outside of the sandbox. The problem with the Deno security model is that it’s hard to predict how granting any specific permission would affect overall security. For example, it may seem to be kinda reasonable for an application to ask for `--allow-write=~/.config` to create config directories & files, but it’s probably explo…
Lots of weasel words here and you don't answer directly. It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions. Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect. Today with Node any random package can download any DLL as long as it is novel enough to…
Whether or not ideas and discussion are negative or positive is not relevant at all. When they're presented in some detail and in good faith, we should tackle them in turn. This encourages thought, discussion, and understanding among all.
Love Deno. So much much more intuitive and simple than Node. I highly recommend you giving it a try, if you used Node before, Deno will be a super easy to learn tool.
Can you elaborate?
Love Deno. So much much more intuitive and simple than Node. I highly recommend you giving it a try, if you used Node before, Deno will be a super easy to learn tool.
> So much much more intuitive and simple than Node. Can you elaborate?
Overall, it just makes sense. It feels like you’re using one syntax for front and backend instead of having to use two different ones.
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.
Earlier quoted context omitted.
Yes, it exploits `--allow-run=whatever` + `--allow-write=whatever` to execute arbitrary code outside of the sandbox. The problem with the Deno security model is that it’s hard to predict how granting any specific permission would affect overall security. For example, it may seem to be kinda reasonable for an application to ask for `--allow-write=~/.config` to create config directories & files, but it’s probably explo…
Lots of weasel words here and you don't answer directly. It still seems to me that a Deno script running with necessary permissions will be a huge hurdle compared to running a Node script which by default has al permissions. Edit : Also I'm seriously fed up with tech community cr#pping at everything good because it isn't perfect. Today with Node any random package can download any DLL as long as it is novel enough to…