Well, there is a known MITM vuln in Deno by design and the team refuses to fix it soooooo
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
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'
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.
Is there any possible way to face this vulnerability without either 1) linking to a resource over HTTP or 2) loading a resource from someone else who linked to another resource over HTTP?
Case one is the devs fault for doing it; case two is also the devs fault for not even checking their dependancies.
As infrastructure grows, there will be tools that either extend the environment to block/log HTTP stuff, or catch HTTP URIs in static analysis. Both of these, specially in combination, would be more than enough.
Knowingly leaving this kind of things in the codebase totally invalidate Deno being secure. There is not possible discussion in 2020 about https not having to be enforced. People thinking otherwise should not be allowed near a computer for their own good.
I know it's not an identical problem, but it does demonstrate that we probably agree that the onus is on the user to assess the risk of any arbitrary code they run on their machine, including the risk associated with the transport they use to obtain that code.
Funnily enough I actually agree with you that I would prefer to prevent http imports by default. However doing so won't make importing a library secure, and conversely allowing it doesn't mean it is insecure.
As an aside, I noticed you have posted the same one line message about the risk of a MITM attack with http imports 4 times in this thread. You might find it more helpful to contribute to the discussion by explaining why you think that.
Linux is not branded as a "Secure thing" right? Here Deno is building marketing on something inacurate.
browsers have been benefiting from decades of innovation to mitigate the security issues of execution of JavaScript.
CORS headers is the latest of theses innovations. Deno allow you to fetch code as a browser would without providing you with any of the safety browsers can have. Mostly because it would not make sense to have a runtime doing that.
Deno is not a browser but takes the risks of a browser. Running Deno install is as safe as browsing the internet using Windows CP without SP 2 and Internet explorer bellow 6.
Also, importing a module in https does not mean this module won't import anything using http. Should you review the code of all imported modules? This is virtually impossible.
Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.
I wouldn't be surprised if this was exactly the direction that Deno was trying to move towards. Fewer direct dependencies with some amount of transitive trust.
I.e. "[Deno] has a set of reviewed (audited) standard modules"
> Windows CP without SP 2 and Internet explorer bellow 6
I get the point you're trying to make with this hyperbole but browsers still let you view http pages (by default).
> Deno must disable http by defaulkt and provide a flag to re-enable it. This is factually a security issue in Deno.
Again I agree with your idea about disabling by default but there is another perspective (and I think Ryan deserves some empathy).
The marketing around Deno has been made toward that and it makes no sense to reach 1.0.0 with such a big security issue unhandled.
Also, this part is even more frightening https://github.com/denoland/deno/issues/1064#issuecomment-43....
At this point, it is clear that Deno is lying for marketing reason by calling itself secure.
Of course Ryan deserves empathy, so does Bert. But in the meanwhile during their talks at major conferences, they have trolled a lot another project. The maintainer of that other project now get weekly/daily pings from deno supporters trolling them.
Deno's culture seems big around trolling atm, a CoC could have fixed it, the th (B)DFL has decided another way.
I'm not familiar with the surrounding politics and don't particularly want to be involved, but I appreciate the explanation.