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

Deno 1.0

deno.land

Post reply on HN
Print view View original

181–190 of 598 posts

Re: Deno 1.0

#181

Post by bgdam »

ricardobeat wrote: post #156
bgdam wrote: post #151

Earlier quoted context omitted.

See the thing about the sandbox is that it's only going to be effective for very simple programs. 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 fro…

Maybe this will develop into a standard of multi-process servers (real micro services you could say), where the permissions are only given to a slice of the application.

Now that would indeed be an interesting way of building servers.

Re: Deno 1.0

#182

Post by littlestymaar »

bgdam wrote: post #151
aazaa wrote: post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > 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…

See the thing about the sandbox is that it's only going to be effective for very simple programs. 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 fro…

For the use-case you describe, your just going to need network access: no file access and no process-forking needed, this is a big surface attack reduction.

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.

Re: Deno 1.0

#183

Post by austincheney »

bgdam wrote: post #139
nitsky wrote: post #137

Earlier quoted context omitted.

In practice modules will be available from sources that will have similar reliability to npm: github.com, unpkg.com, cdn.pika.dev, jspm.io, etc.

Which then raises the question - how is it better than NPM? If there are going to be centralized repositories (like NPM), and if I have to download my dependencies into a $DENO_DIR (like NPM), and if I am then loading these dependencies from local files (like NPM), how is it any different to NPM? Except for being less secure by default? This is starting to look like a case of being different just so you can say you'r…

NPM is a dependency management failure which is why you are ending up with hundreds of dependencies in the first place. It sounds like you want to reproduce that insanity in Deno. Deno is set up in such a way to dissuade you from the stupidity by default but allow it in very few steps if you cannot imagine a world without it.

In my opinion this is Deno’s biggest selling point.

Re: Deno 1.0

#186

Post by littlestymaar »

bgdam wrote: post #127
batmansmk wrote: post #117

Earlier quoted context omitted.

Hi! The response to your fears are in the announcement. "If you want to download dependencies alongside project code instead of using a global cache, use the $DENO_DIR env variable." Then, it will work like node_modules.

Ah, in this case, I would then have to commit my dependencies into my VCS to maintain reproducible builds. I'm not sure I like that solution very much either. I've seen node_modules in multiple GBs, and I'm sure Deno's dependency sizes are going to be similar.

True, but that's what people using Go have been doing for years without complaining much, so I guess it works fine for most workload.

And before npm fixed things after the left-pad incident, the npm builds where not reproducible either (as demonstrated by the said left-pad incident).

Re: Deno 1.0

#187

Post by pedalpete »

megavolcano wrote: post #103
eyelidlessness wrote: post #92

Earlier quoted context omitted.

> It's basically the same "exposure" as importing a random npm, but it has the benefit if being explicit when you do it. This is definitely false. For all the problems with the NPM registry and the Node dependency situation, an NPM package at a specific version is not just at the whims of whatever happens to be at the other end of a URL at any given moment it's requested. This is a huge vulnerability that the Node/NP…

Deno has lock files and caches files locally on first import.

yeah, but we regularly clear out our cache and lock files, so this doesn't really solve the issue, unless you're commiting all of your packages

Re: Deno 1.0

#188

Post by austincheney »

pedalpete wrote: post #44

Does anyone else see the import directly from URL as a larger security/reliability issue than the currently imperfect modules? I'm sure I'm missing something obvious in that example, but that capability terrifies me.

How is it any different than how it works in the browser?

Re: Deno 1.0

#189

Post by james-mcelwain »

bgdam wrote: post #153
batmansmk wrote: post #147

Earlier quoted context omitted.

To solve your issue, you would do exactly how you do your node deployments: download the deps in a folder in CI, then deploy the whole build.

Except that now, the download deps in CI step can fail if one of hundreds of websites for my hundreds of dependencies goes down. If the main NPM repository goes down, I can switch to a mirror and all of my dependencies will be available again.

I'd highly recommend mirroring packages anyway. Obviously this isn't always necessary for small projects, but if you're building a product, the laws of the universe basically mandate that centralized package management will screw you over, usually at the worst possible time.

Re: Deno 1.0

#190

Post by littlestymaar »

fiddlerwoaroof wrote: post #159
fermienrico wrote: post #124

Earlier quoted context omitted.

I think the primary way to manage dependencies should be in a local DIR and optionally, a URL can be specified. The default in Deno is questionable choice. Just don't fuck with what works. Default should be safest followed by developers optionally enabling less safe behaviors.

Using a universally unique identifier like a URL is a good idea: this way, https://foo.com/foo and https://bar.com/foo are distinct and anyone who can register their own name gets a namespace, without relying on yet another centralized map of names->resources. After all, the whole point of a URL is that it unambiguously identifies resources in a system-independent way.

Good luck finding which of foo.com/foo or bar.com/foo is the foo module you want though…
Post reply on HN