EDIT: I mean hashes of dependencies.
That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting.
Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.
That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http
import { dependency } from 'http://whatever.url/@1.0.3'
with hash '6f09aa686a6263f9e992'
or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash function). This can be transitive if the dependency also has hashes of its dependencies directly inside it (and a "only allow that" mode could enforce it).The additional benefit is that you also don't need to trust the server to not replace code for a URL under your nose from one you have previously verified. So like a lockfile, but without needing to download a separate file (because you also want verification on the first run) and a command-line argument on launch - which makes it a much more viable replacement for bash scripts (in fact, that's why I care about the ability, I wouldn't mind https-only). Am I missing something here?
According to them, confidentiality is also a risk. also someone could also send you garbage that would polute the memory of deno until it explode.
For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!
I would prefer https-only, sure, but it doesn't buy you very much security.
I don't want to write an full lecture on how many attacks are possible when people don't use https. It has been commmon knowledge for way more than a decade