[LunaSea]

> What's so bad about package management?

Hard coding URLs is significantly worse than having a package.json file:

- you don't need to write the full URL to import a module

- you have a quick overview of which modules are installed and for which reason (dev dependencies)

- you can easily create an immutable list of dependencies

> And what's useless about the security harness

Because most apps will have to enable all flags (file system and network) anyway and because huge security holes like symlinks breaking out of the harness were present not too long ago.

[hobofan]

- URL-based dependencies also have some additional security issues in the most common usage scenarios (see my recent flagged post: https://news.ycombinator.com/item?id=34937327).

- You also lose all ecosystem upgradability, as everyone is using pinned versions instead of SemVer ranges

[tracker1]

How many things have been broken by doing that in practice though?

I mean seriously... in node/npm, I've seen way too many times where a minor version broke things in practice... so we go to patch level by default, usually safer... In the end, we still wind up needing tools, like with github to alert to issues that require larger bumps.. Oh, your application hasn't been updated in a year, and you now have two major versions of LibraryX to run through... Next thing you know, you've spent literally three weeks to update your node/npm/react project... and even then, some packages were too painful to update, so you just deal with the warnings anyway.

And, now you've concentrated targets to the latest minor/patch versions in packages... where if everyone is pinned, the targets are mostly unknowned from outside without deeper inspection.

Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

[hobofan]

> Just saying, I'm not sure auto semver with lockfiles is really a win over just locking to begin with.

It's still a win even if you consider only patch version updates. Without that, for a CVE in a dependency, every dependent package will have to update, and will first have to wait for the lower level to update and publish a new version. So for a dependency ~4 layers deep, with coordination and publishing lag in between, this can quickly take more than a week (and this is assuming responsive maintainers).

[tracker1]

A lot of time that happens anyway... at least with npm... there are a lot of times you see warnings, that you cannot resolve because of a nested dependency that is more than a point release off.

[vanjajaja1]

The world will take some time to adapt to correct security mechanics, just like all other software worlds did. The security harness is not only a security harness, its a whole layer that abstracts away access to the operating system.

[LunaSea]

But it's the wrong approach.

The correct approach would have been through syscall blocking which is a much lower level.

[vanjajaja1]

I'm assuming you mean SELinux style sys call blocking. I think you need both - syscall blocking for the system/deno layer, which enables app layer security in deno itself. That would be the composition-over-inheritance / functional approach.