Comment by rubenfiszel | Hacker News Reader

Comment by rubenfiszel | Hacker News Reader

Parent Full thread

Wanted to shime in on this since we are big supporters/users of deno and building an OSS enterprise-grade platform for a self-hosted lambda that runs deno scripts among others [1].

I think this is unfair because npm has its own set of issues, most notably, 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, it takes a bit more than just an innocent npm install to break things.

The real security for scripts is in the sandboxing, permissioning model and providing self-contained scripts that you can read and analyze in one go. So far, node doesn't offer that experience yet. Deno is the leader of innovation in that specific area. It was a bold move and that it is moving back to node compatibility has a lot more to do with network effect and first mover advantage than an inherently bad design.

Bun is likely to have made the correct move by focusing on performance and node compatibility from a business/adoption standpoints (and we will add bun to our supported env as a consequence), but from a security perspective, deno is still the cutting-edge.

[1]: https://github.com/windmill-labs/windmill

It is also the norm to strictly pin dependency versions in the npm-ecosystem, at the project-level, via lockfiles. So simply doing an `npm install` in an existing project won't install the new trojan.

Yes, versions aren't usually pinned at the package-level, so if you install a new dependency that introduces the trojan to the project, then yeah your are compromised. Not sure if that happens to "millions of servers" in a few weeks tho, it'd have to be a pretty popular package at least and remain undetected when these millions of developers presumably test the new code that their new dependencies introduce.

Having versions tightly pinned in the package-level isn't a free gift. It'll lead in lots of duplicated versions of a practically same package being installed and ran when two higher level dependencies have a transitive dependency to sligthly different (but in practice compatible) versions of the same package.

Edit: I agree with the points about sandboxing and permission configuration, etc, though. That's hopefully also coming to Node at some point.

It seems to me that the norm in the node world is to use ^ specifier to say anything that is non-breaking, and that `npm install` will not respect the package-lock.json, only `npm ci` does.

> and that `npm install` will not respect the package-lock.json

I'm not sure where you get that from. Maybe this was the case for the first NPM version with package-lock.json, but at least for the current and previous LTS version, it is definitely being respected.

This is correct up to a point (which is why npm ci exist at all), I agree that in general since you would have to mutate the package.json for that to happen, my point is moot (https://stackoverflow.com/questions/45022048/why-does-npm-in...) but npm install will overwrite the package-lock.json if they do not match.

> 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.

Reply on news.ycombinator.com