Hacker News new | ask | show | jobs
by dmitriid 1621 days ago
Mentions security and then completely glosses over security in the section on "yeah, we load random modules from URLs but it's okay because most Deno registries are immutable and we cache files"
3 comments

If you care about security you will have setup your own node package registry with a curated/audited list of dependencies, then you need to point to the registry for the dependencies and maintain the registry.

With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map[1], the browser will take care of download/cache them all.

[1] https://wicg.github.io/import-maps/

> If you care about security you will have setup your own node package registry with a curated/audited list of dependencies, then you need to point to the registry for the dependencies and maintain the registry.

Exactly. And it's quite easy to do.

> With deno it should be easier to do this, you setup your own cdn, just upload plain js files and point it from your import map

I was waiting for the inevitable just.

- Just set up your own CDN.

- Just upload a plain js file there (where do I get those files from?)

- Just point to dependencies using a feature that, quote "is not a W3C Standard nor is it on the W3C Standards Track"

- And then the browser... record scratch who said anything about a browser?

And we have lock files to verify integrity. This is no different to module loading in Node. If you don’t trust your registry, you should not be loading code from it!
> And we have lock files to verify integrity.

Where do you et these lockfiles files from?

> This is no different to module loading in Node.

This is very much different from module loading in Node: https://news.ycombinator.com/item?id=29871936

> If you don’t trust your registry, you should not be loading code from it!

So you immediately pinpointed the difference: with Node I can run my own registry and easily set up npm/yarn to never load packages from anywhere else. Deno loads code from random urls.

> So you immediately pinpointed the difference: with Node I can run my own registry and easily set up npm/yarn to never load packages from anywhere else. Deno loads code from random urls.

Which is why we support a) import maps which allow you to rewrite all URLs however you want, and b) HTTP_PROXY, which allows you to intercept all HTTP traffic (also letting you rewrite all specifiers).

I don't know if you have ever worked on a Go project, but it has a very similar registry proxy situation as Deno. It works well.

> Where do you et these lockfiles files from?

I don't know about any lock files but the `version` it locked via the import url E.G import R from 'https://deno.land/x/rambda@v7.0.1'

This brings us back to the fact that Deno loads random files from random URLs with no way to change it. https://news.ycombinator.com/item?id=29871936
> with no way to change it

You are so wrong. If you would have done maybe 3 minutes of Googling you would know we support import maps, which allow you to arbitrary rewrite specifiers, even deep inside of the module graph.

sure but is that not how a browser works?

for example to add bootstrap to a site you import like this

<script src="https://cdn.jsdelivr.net/npm/bootstrap@5.1.3/dist/js/bootstr..." integrity="sha384-ka7Sk0Gln4gmtz2MlQnikT1wXgYsOg+OMhuP+IlRH9sENBO0LRn5q+8nbTov4+1p" crossorigin="anonymous"></script>

which is exactly the same as deno's "loads random files from random URLs"

> sure but is that not how a browser works?

Deno is not a browser.

> for example to add bootstrap to a site you import like this

I know how to import a file in a browser. However, Deno is not a browser. The whole subthread is about managing dependencies, which Deno fails at, and its proponents come up with the most ridiculous things to justify it.

> Where do you et these lockfiles files from?

At dev time, you generate a lock file of the hashes of your dependencies. You commit this file to your code repository.

When getting dependencies, the hash of the downloaded dependency is compared to the one in the lockfile.

> At dev time, you generate a lock file of the hashes of your dependencies.

So. At dev time. You download random files from random urls via Deno.

Compared to: At dev time you download files from a trusted repository. https://news.ycombinator.com/item?id=29871936

NPM is not a trusted repository, I think. There are no checks done to the content of the packages uploaded by users. It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.

If you use a lockfile, downloading a package from NPM or directly using a random URL is conceptually the same, since they are both untrusted sources. Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.

> NPM is not a trusted repository

It's not. But it's rather trivial to run your own registry, and many (most?) companies do exactly that.

> It's up to you to make sure that what you add to your project doesn't contain malware/vulnerabilities.

That's why, again, many companies run their own registries, and don't download random files from the internet.

> Having a lockfile will ensure that if you download a dependency to review it for vulnerabilities, later re-downloads of the dependency will not have changed files.

And to generate that lockfile... you need to first download a random file from the internet. Got you.

there is not really a difference between a url to a registry and a npm package name.

the different approach would be yarn's saving zipped versions of packages, I don't know if deno supports it

> there is not really a difference between a url to a registry and a npm package name.

There is. For starters, I can run my company's registry and make sure all npm packages are downloaded from there since resolution mechanism for npm/yarn is well known.

How do I tell deno to download <random-url> from my own registry?

Looking at how deno "solves" this I can't stop laughing [1]

--- start quote ---

In Deno there is no concept of a package manager as external modules are imported directly into local modules. This raises the question of how to manage remote dependencies without a package manager. In big projects with many dependencies it will become cumbersome and time consuming to update modules if they are all imported individually into individual modules.

The standard practice for solving this problem in Deno is to create a deps.ts file. All required remote dependencies are referenced in this file and the required methods and classes are re-exported. The dependent local modules then reference the deps.ts rather than the remote dependencies...

With all dependencies centralized in deps.ts, managing these becomes easier.

--- end quote ---

Are you for real?

[1] https://deno.land/manual/examples/manage_dependencies

There is one difference. I know npm keeps published versions. I don't know that random URL keeps versions. Caching locally doesn't help. I expect my code to work for others. Of course using any source is nice. node also allows this, just put a git URL as your dependency.
URLs to a registry keep published versions if the registry keeps published versions.

Your argument is that npm is more trustworthy than another random registry, this is likely true but also a matter of opinion.

> URLs to a registry keep published versions if the registry keeps published versions.

Yes. Have you've ever heard of running your own registry? It' quite easy to do and most companies do it prcisely because they want to a) keep published versions and b) prevent things like colors/fake.js

Literally no one who promotes Deno has yet shown how to do the same with Deno beyond "yeah, you check in all your node_modules dependencies into Git".