> if anyone were to sneak up a non obvious trojan horse into the dependency chain, it would take a few weeks to be detected and millions of servers would alread

> if anyone were to sneak up a non obvious trojan horse into the dependency chain, it would take a few weeks to be detected and millions of servers would already be compromised. You can do this with deno too but the norm is to use pinned version and a deps.ts. Only for consumers that blindly auto-update dependencies. The norm in the NPM world has also finally arrived at having a lockfile, so your are using pinned versions as well. The lockfile also has the additional benefit of reducing the impact of updating an individual dependency, as the resolution mechanism doesn't have to start from scratch and only a small part of the dependency tree will be updated. With Deno's exact version pinning one is on the other hand significantly more exposed to CVEs in transitive dependencies, as one would have to rely on all dependencies to update their dependencies and coordinate the fixes throughout the ecosystem. In a system that is based around SemVer ranges and automated dependency resolution, one "only" has to bump the version to that transitive dependency. This could be remedied a bit in Deno by allowing URLs to be globally rewired (or mirroring/forking the whole dependency chain), but as far as I can tell this mechanism/tooling doesn't exist in Deno (yet). > I think this is unfair > sandboxing, permissioning model > Deno is the leader of innovation in that specific area. I think the only point that is unfair was the "the Deno teams stance on security is not so funny" (and I would strike it now if HN would still let me edit the post). You are right that their efforts on the sandboxing front is very commendable. However, the overall package (including their dependency management), doesn't feel thought through security-wise, and their URL-focused dependency story opens a lot of additional security holes.