URL modules and security

[Chrisstar56]

I want to get started using Deno but either I misunderstood some core concepts or this really an issue. From what I understand Deno loads all modules on first import and then caches them indefinitely (until you force a reload). My question now is, without some kind of package manager, how can Deno insure quick security updates in modules. Is this even possible without some kind of central authority?

Maybe Deno should think about the option of providing a package information tool (customizable source, but by default deno.land?). Also some kind of option to search for packages would be great. With npm I can just search by keywords and will pretty quickly find what I need.

[rsp]

You are talking about few different things here.

First, for security audits, I believe that I used Snyk before there was npm audit so there is no reason we couldn't have third party tools to audit and update imports. Snyk wasn't and still isn't officially endorsed by npm and works just fine.

Second, to search for modules we could have multiple search engines with different features with no need to have a centralized one. Also remember that not all Node modules are on npm. Some are on GitHub and can be installed with npm install user/repo but they are not on npm and will not be shown by npm's search engine.

Also, there are services like GitHub Packages: https://github.com/features/packages that let you publish Node modules in places other than npm so even in Node npm is not the only place to sarch for packages. It may be the biggest one right now, just like deno.land/x is the biggest place to search for Deno modules, but not all Node modules are on npm just like not Deno modules are on deno.land/x.

For the package information tool, anyone can write a tool like that. All data is in:

https://github.com/denoland/deno_website2/blob/master/src/database.json

[lucacasonato]

@Chrisstar56 https://deno.land/x provides a registry for all kinds of modules (with search). Is there a concrete feature you are proposing? Otherwise it sounds like this issue can be closed.

[andykais]

I do think there is one issue that deno is not able to solve currently, that npm modules can.

My question now is, without some kind of package manager, how can Deno insure quick security updates in modules.

Ignoring the issue of actually discovering security flaws in packages for a moment, there is still the matter of discovering where a vulnerable package is used within a project, and then updating it. With a npm package-lock.json file, it is easy to see which toplevel packages have security vulnerabilities, or more often, dependencies with security flaws. If I see that lodash has a recent security bug, I can run npm ls <package_name> in my project and see which of my packages depend on it.

npm ls lodash
scrape-pages@3.5.0 /Users/andrew/Code/scratchwork/scrape-pages
├─┬ @microsoft/api-extractor@7.8.2-pr1796.0
│ └── lodash@4.17.20
├─┬ @typescript-eslint/parser@2.34.0
│ └─┬ @typescript-eslint/typescript-estree@2.34.0
│   └── lodash@4.17.20  deduped
├─┬ chai-deep-match@1.2.1
│ ├── lodash@4.17.20  deduped
│ └─┬ lodash-pickdeep@1.0.2
│   └── lodash@4.17.20  deduped
├─┬ cheerio@1.0.0-rc.3
│ └── lodash@4.17.20  deduped

then if I know that the vulnerability exists in lodash@4.17.20 and is fixed in lodash@4.17.21, I can manually edit the package-lock.json file so the packages that are slow to send out fixes (or worse, are abandoned), will still be working with safe code. This is what npm audit --fix does, so when using npm, the process is really just running one command. Its hard to argue that changing dependencies out from under a package is a good idea, but if packages follow semver, then a PATCH version change should be a safe change.

Correct me if Im wrong, but I dont believe there is a to update a nested module inside deno. I know that deno info exists for displaying a module tree, but how can a user change the version of a deeply nested module? Perhaps with import maps?

[Soremwar]

@andykais You can't, the dependencies of your libraries are out of your reach (that's why things like peer-dependencies cause no trouble in Deno).

What you could do is fork the code of the library (eg: fork it in GitHub) and then import the library from your fork instead of the main source.

This might sound like a troublesome process for something as simple as updating a library, but is definitely safer than changing the peer version and hope the library you use follows Semver. This also helps us kind of push forward abandoned libraries in a way NPM couldn't.

[andykais]

@Soremwar thats fair enough, I understand the philosophies are different. I just wanted to lay out the tradeoffs between node modules and deno modules

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[lucacasonato]

Nothing actionable here. Discussions like these are better suited for https://github.com/denoland/deno/discussions, or https://discord.gg/deno

[fkirc]

Please correct me if I am wrong, but it is still a mystery to me how “raw URL imports“ can solve the problem of duplicate or insecure dependencies.

Let’s assume the following scenario:

• My project depend on A and B
• A depends on C 1.0.1
• B depends on C 1.0.2

How can I prevent that C is duplicated in my project?
In the worst case, such duplicated dependencies with slightly different versions might not only bloat up my bundle size, but trigger real security problems.

npm solves this problem through a deeply nested package-lock-file, to ensure that dependencies are both deduplicated and securely locked with hashes.