Hacker News Reader

Comment by DarkWiiPlayer | Hacker News Reader

That's really just a HTTP problem though, isn't it? If you use HTTP, you're exposing yourself to MITM attacks; that's on you.

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.

View on HN

well, most of Deno marketing is that it is safe by default. In 2020, not enforcing a secure protocol to share source code is a no go at all. I really don't get your point here defending something that has not made any sence since the end of last decade.

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.

Would you say linux is insecure because a user can download an arbitrary shell script and run it?

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.

> Would you say linux is insecure because a user can download an arbitrary shell script and run it?

Linux is not branded as a "Secure thing" right? Here Deno is building marketing on something inacurate.

Most people describe Linux as a much safer OS even though windows puts more restrictions on running code from the internet (to the extent of marking downloaded files as potentially dangerous and asking if you really want to execute them). I would totally understand if HTTP(not s) was used by default at any point, but by writing a URI starting with `http://` into the file, the programmer is actively telling the program to download that file and use HTTP for that. Secure by default doesn't mean preventing the programmer from doing insecure things.

Let me tell it another way:

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.

> Should you review the code of all imported modules? This is virtually impossible.

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).

At this point, there is clearly a vuln in a tool that brands itself as secure and in opposition with another project.

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.

It seems like this is not simply about the decision of whether to allow http by default and security of dependencies.

I'm not familiar with the surrounding politics and don't particularly want to be involved, but I appreciate the explanation.

Reply on news.ycombinator.com