if you require modules by URL, how does it make sure that the URL always contains the same library? I've read the docs and it says it caches on the initial execution and doesn't update unless it's forced to update, but what happens when you for example publish a deno module to github, and someone else downloads it and runs it, and turns out the URL contains completely different library at his execution point?
This is something that we'll further work out in future versions. For now you can use a lockfile: https://deno.land/manual/linking_to_external_code/integrity_...
Instead of referring to the version could you refer to the hash? Then a simple integrity checker could confirm file changes.
It's not just about the integrity. The url may very well provide what they claim to provide, so checksums would match, but it's the direct downloading and running of remote code that is terrifying. This is pretty much like all the bash one-liners piping and executing a curl/wget download. I understand there are sandbox restrictions, but are the restrictions on a per dependency level, or on a program level? If they ar…
If you afraid of "direct" downloading and executing some of that code, then what do you think happen when you npm install/pip install a package? I'm very interested if you can expose a new attack vector that didn't exist with the previous solutions.
You can generate modules on the fly on the server, that require next generated module recursively blowing up your disk space. If deno stores those files uncompressed, you can generate module full of comments/zeros so it compresses very well for attacker and eats a lot of space on consumer side.
> ... 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…
If I am building a real world application I'm going to vet the libraries I use.
I guess it would depend on the JS engine. If the player is the one writing JS, and you want a scaled down environment (since it's not an app in the browser), probably making your own JS parser/engine could be the way to go? You'd want the JS engine to be inside the game engine somehow.
> and you want a scaled down environment This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes). > probably making your own JS parser/engine could be the way to go That sounds like a lot of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards,…
Yeah I can't comment much on how long a JS engine would take. You could start using V8 I guess, but I would think using an existing JS engine inside a game engine might by tricky because they seem complex. JS the language is easy to create a parser for, and that might be what you really want to be custom in order to do other things in between the JS code. Maybe try looking for stripped down JS engines that have source code to see how hard it is. I'm also assuming you will code this game with C++ for performance, but maybe a JS/HTML game could leverage V8 from the browser, if that was your initial thinking.
> ... 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…
> means it's going to be much less secure than the already not-that-secure NPM ecosystem.
I have only the bare minimum of like, experience with nodejs. Would you mind fleshing out why that is so?
> and you want a scaled down environment This is definitely a requirement, a very scaled down one since I don't want any interaction with the outside world apart from the game engine (for determinism purposes). > probably making your own JS parser/engine could be the way to go That sounds like a lot of work to do well. If I had infinite time I suppose re-implementing a common language would be the best way forwards,…
Yeah I can't comment much on how long a JS engine would take. You could start using V8 I guess, but I would think using an existing JS engine inside a game engine might by tricky because they seem complex. JS the language is easy to create a parser for, and that might be what you really want to be custom in order to do other things in between the JS code. Maybe try looking for stripped down JS engines that have sourc…
I'd be delighted to use V8... if I could figure out a way to get a deterministic estimate of the runtime of scripts (e.g. in languages that compile to a bytecode I could add a "bytecodes executed counter" easily enough).
I'm coding the game in Rust, but I really don't care what the language is coded in, linking in a language runtime isn't a problem.
I am happy to see Deno v1.0 is out now. I like the ES modules support, TS first approach, top level async/await, etc. It compiles and caches the TS files, don't need additional setup to support TS right away.
I am not sure about not using the package.json though, I kinda like it as it is the central point to manage all dependencies in NodeJS projects.