Recommend sub-resource integrity [SECURITY]

[fulldecent]

The project scope identifies that Deno aspires to be a "secure" runtime in the readme.

Lower on the page, an example is shown of loading code directly from a URL.

deno run https://deno.land/std/examples/welcome.ts

loading resources only using a URL is notoriously insecure. Best practice for loading code using a URL is to use sub-resource integrity. This is because loading a URL could produce any code that will be run on your computer. And furthermore, there is probably no logging by default in Deno, so a malicious actor will take over your machine while also maintaining plausible deniability, which is 🆖.

By default, please recommend that usage on the command line will require SRI. For example, that command could be.

deno run https://deno.land/std/examples/welcome.ts 7353d5fcbc36c45d26bcbca478cf973092523b07c45999f41319820092b4de31

Furthermore, running Deno in this mode should reject any recursive includes from that above URL unless they do similarly include some SRI hash of what they are expecting to include.

---

If Deno does not wish to handle the case that a URL hosting code could change (i.e. you don't want SRI), then please update the README to say above that example:

WARNING: This example will run whatever code is at that URL in your Deno runtime. And because URLs can host any content at any time, changing without warning, even automatically based on your user agent, this approach is insecure and you should not trust it.

[Soremwar]

That specific example can't endanger the user's computer because it's being run without any permission arguments, which are explained in the Deno manual and protect the user agains this very problem.

About how URL content can change at any moment, that depends a lot on the provider. By using registries like deno.land/x and nest.land you are always guaranteed to get the same content, in a similar fashion to how NPM does it.

[lucacasonato]

loading resources only using a URL is notoriously insecure

Says who? We are loading resources over HTTPS - if you trust the domain you are importing from (certificate must be valid for Deno to download the script), then you are fine. npm install is only "secure" if you trust that npmjs.org is not compromised.

This is because loading a URL could produce any code that will be run on your computer.

Wrong. This code will be fully sandboxed because you specify no permission arguments. It won't even have access to high res timers, let alone disk or network.

The web has been loading files from URLs for forever. The same best practices apply - dont import from an origin that you do not trust.

FYI Deno has a --lock argument if you want to make use of subresource integrity. SRI is not any more secure than not having it in most cases anyway. If you get the SRI hash from the same location you got the URL to download, how do you know an attacker did not forge the SRI hash?

Respectfully closing.

[fulldecent]

SRI is secure because you receive it from a separate channel.

To illustrate, you load https://deno.land and on that page it loads JavaScript (for example) from the Bootstrap project using:

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.0.0-beta3/dist/js/bootstrap.bundle.min.js" integrity="sha384-JEW9xMcG8R+pH31jmWH6WWP0WintQrMb4s7ZOdauHnUtxwoG2vI5DkLtS3qm9Ekf" crossorigin="anonymous"></script>

The hash is provided by you but the included file comes from elsewhere.

This is why SRI is used by the Bootstrap project, which I respect, and it is a well-recognized best practice.

[lucacasonato]

This is effectively a duplicate of #10008. The points described there also apply here and vice versa. Security only works with trust. If you do not trust us, our webservers, or our security management of these servers, I don't see why you would be using Deno.

[fulldecent]

A hypothetical user should trust Deno to make a good runtime for JavaScript.

"Hosting a secure webserver that won't get hacked in an impossible-to-diagnose way that is targeting high-value developers and sysadmins" is not a part of the project scope.

Therefore trusting the Deno project to do that is inappropriate.

Now, if the README were updated and said:

Deno is a simple, modern and secure runtime for JavaScript and TypeScript that uses V8 and is built in Rust and we host a secure webserver, hosting and SSL infrastructure.

then I would believe you.

You might say "secure webserver, hosting and SSL infrastructure" is redundant for any project. But it is not. Linus uploads tarballs for Linux using FTP (or used to). They are entirely secure even though he does not manage web servers, or SSL, or other things. And that is because his security implementation is good -- specifically, he signs the packages with a digital key that is well known.