Lockfiles should be used for production code, as per https://deno.land/manual/linking_to_external_code/integrity_...

Can checksums/hashes be specified directly in the source file?

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.

>Can checksums/hashes be specified directly in the source file?

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

How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains

    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?

Oh, I did not get what you meant ^^ well, there are still other issues than integrity with not using https.

Yeah, I'll edit the original comment to clarify that I mean hashes of dependencies.

there are a lot of issues with using a non secure protocol to do anything over the internet, actually someone summarized the issue on the Deno issue tracker.

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.

That is not enough at all and there are other attacks! I can't belive in 2020 some people still need to be explained why not enforcing https is a terrible thing!

For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!

https prevents MITM but doesn't prevent the modules being backdoored or otherwise altered at the source.

I would prefer https-only, sure, but it doesn't buy you very much security.

Well, diasabling http by default is basically "Internet 101" here.

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

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.

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.