If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs.
For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code from any url and run it immediately', means it's going to be much less secure than the already not-that-secure NPM ecosystem.
What protection does NPM actually give you?
Sure, they'll remove malware as they find it, but it is so trivially easy to publish packages and updates to NPM, there effectively is no security difference between an NPM module and a random URL. If you wouldn't feel comfortable cloning and executing random Github projects, then you shouldn't feel comfortable installing random NPM modules.
> and run it immediately
NPM packages also do this -- they can have install scripts that run as the current user, and have network access that can allows them to fetch, compile, and execute random binaries off the Internet.
From a security point of view, Deno is just making it clear up-front that you are downloading random code snippets, so that programmers are less likely to make the mistake of trusting a largely unmoderated package repository to protect themselves from malware.
I lean towards calling that a reasonably big security win on its own, even without the other sandboxing features.
Dependency version pinning comes to mind. The main difference between this and a random URL is that at least you know that if the module gets bought by a third party, your services or build system won't auto update to some rando's version of the package. IIRC there have been cases when a version was replaced as well.
I think this could be fixed quite easily if one could add a hash and a size after the url, to force a check.
Or similar to node_modules, have some way to pull your dependency graph & host locally — At least for enterprise-y adoption I imagine that people will want to have _their_ copy of the code and choose when to update it even if in theory the remote code is locked down.
These concerns and the conversation around them are good and healthy. Give it some time. People will experiment with what works and over time best practices will emerge for the set of trade offs that people are willing to make.
Well, using message digests, NPM or Yarn can pretty much guarantee content addressable versions, too. Do not have to use IPFS or blockchains, just because...
What deno does is move package management away from the framework distribution. This is great - one thing I hate about node is that npm is default and you get only as much security as npm gives you. (You can switch the npm repo, but it's still the overwhelming favourite because it's officially bundled.)
Deno can eventually give you:
import lib from 'verified-secure-packages.com'
import lib from 'packages.cloudflare.com'
iptables + namespaces gives you the rest.
NodeJS is also working on policies (1) which allows you to change permission to single modules or files.
But indeed, if there is a separate user account for the application, then chmod can be used for some control to its access to files and directories.
For the network access I have an issue[0] open that asks to separate permissions to listen on the network from permission to dial. Also, along the way I want to have the ability to let the OS pick the port as an option.
Permissions are meant to work by whitelisting. So you wouldn't open access to the whole system just to talk to your DB, or to operate on some files.
That means that I am actually a lot more vested into it, and if I want to put it in production, then I have to be concerned about things like this.
When somebody says they think X is broken, and they present a solution Y which they say is better, I am definitely entitled to ask why they think Y is better when I can't see the difference.
You're entitled to your opinion, of course. I had to read through the docs to understand their module system and intent. And I find it very exciting.
” We feel that the landscape of JavaScript and the surrounding software infrastructure has changed enough that it was worthwhile to simplify. We seek a fun and productive scripting environment that can be used for a wide range of tasks.”
Sounds intriguing to me. As a fan of starting projects of as simply as possible, I will certainly be tinkering with Deno.
yarn global add ts-node prettier
echo 'alias deno="ts-node"' >> ~/.zshrc
echo 'alias deno-fmt="prettier --write"' >> ~/.zshrc
Internals are nicer but that's with anything without ugly legacy.
They are working to get node_modules work in deno so I am kind of worried that it will be nodev2 all over.
Moreover Idk how granular the network permission is, but if its implementation is smart, you could block almost all outbound network access except the ones to your DB and the few API you may need to contact.
I have only the bare minimum of like, experience with nodejs. Would you mind fleshing out why that is so?
I think that overall you're right, but it's worth noting that deno can restrict file system access to specific folders and can restrict read and write separately. It's plausible to me that you could have a web server that can only access specific folders.
If you don't need the firewall, you can just run in a chroot under a low-privilege user.
I mean, if you do otherwise, you are not following best practices and the voice of reason.
<url><newline><size in bytes><newline><hash>
import { serve } from deno.http.server;
Most people would want the option to do dependency management on a per-project basis as well. Simply allow a command-line parameter to provide one or more other directories to source from first (besides presumably the global one for your installation).
If we wanted the file to be generated automatically, maybe something like this:
import { serve } from deno.http.server at "https://deno.land/[email protected]/http/server.ts";Not saying that makes it a bad idea, but importing/downloading trusted code over http(s) is not simple even if the protocol sorta is.
Yup! I am really excited about Deno and curious about how popular it will be in a few years.
Servo is absolutely not production ready. A couple of particular pieces of Servo, such as Stylo and WebRender, can be considered production-ready, but no so much the project as a whole.
> ...
> Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The browser provides APIs for accessing cameras and microphones, but users must first give permission. Deno provides analogous behaviour in the terminal. The above example will fail unless the --allow-net command-line flag is provided.
The Deno feature that seems to draw the most fire is dependency management. Some skeptics may be latching onto the first point without deeply considering the second.
Deno is just doing the same thing a browser does. Like a browser, there's nothing that JavaScript running on sandboxed Deno can do that a browser can't - in principle. So the security concerns seem a little over the top.
The one caveat is that once you open the sandbox on Deno, it appears you open it for all modules. But then again, that's what NPM users do all the time - by default.
As far as criticisms around module orchestration, ES modules take care of that as well. The dependency graph forms from local information without any extra file calling the shots.
This seems like an experiment worth trying at least.