Live data from Hacker News

Deno 1.0

deno.land

451–460 of 598 posts

Re: Deno 1.0

#451
Number of things come to mind:

- How do you update dependencies? They are urls spread along many files which can be everywhere... Do I have to find and replace every import statement?

- In some enterprise environments, we use mirroring of package distributors (Nexus, jfrog etc.). This give us the ability to audit what packages are being imported, create a cache of packages so that a single delete or unpublish (like good old leftpad) won't break all applications, etc. Since package locations are hard-coded in the package files, it becomes challenging to do this.

The argument that deno is mimicking a browser is thin. Browsers are client side, they don't access databases or lives inside your firewall. Server applications are much more sensitive to security issues than browsers.

Re: Deno 1.0

#452
post #151
post #138

> ... Deno is (and always will be) a single executable file. Like a web browser, it knows how to fetch external code. In Deno, a single file can define arbitrarily complex behavior without any other tooling. > ... > Also like browsers, code is executed in a secure sandbox by default. Scripts cannot access the hard drive, open network connections, or make any other potentially malicious actions without permission. The…

See the thing about the sandbox is that it's only going to be effective for very simple programs. If you're building a real world application, especially a server application like in the example, you're probably going to want to listen on the network, do some db access and write logs. For that you'd have to open up network and file access pretty much right off the bat. That combined with the 'download random code fro…

I don't think running a public web server application is one of the envisioned use cases here. It looks like a tool for quickly and dirtily getting some job done. But I agree that to get something useful done, you probably need to open up a bunch of permissions, so you're still running arbitrary code on your machine.

Re: Deno 1.0

#453
post #445

Earlier quoted context omitted.

Can checksums/hashes be specified directly in the source file? EDIT: I mean hashes of dependencies. That is important for single-file scripts, if this is meant to be useful as a bash replacement for scripting. Having to download two separate files for a script and execute it with special arguments already adds too much friction to that scenario.

>Can checksums/hashes be specified directly in the source file? That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http

How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains

    import { dependency } from 'http://whatever.url/@1.0.3'
        with hash '6f09aa686a6263f9e992'
or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash function). This can be transitive if the dependency also has hashes of its dependencies directly inside it (and a "only allow that" mode could enforce it).

The additional benefit is that you also don't need to trust the server to not replace code for a URL under your nose from one you have previously verified. So like a lockfile, but without needing to download a separate file (because you also want verification on the first run) and a command-line argument on launch - which makes it a much more viable replacement for bash scripts (in fact, that's why I care about the ability, I wouldn't mind https-only). Am I missing something here?

Re: Deno 1.0

#454
post #445

Earlier quoted context omitted.

>Can checksums/hashes be specified directly in the source file? That would defeat their point actually :D malicious attacker could inject any script by hacking on the network and replace modules that are downloaded through http

How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains import { dependency } from 'http://whatever.url/@1.0.3' with hash '6f09aa686a6263f9e992' or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash…

Oh, I did not get what you meant ^^ well, there are still other issues than integrity with not using https.

Re: Deno 1.0

#455

Of all the problems with NPM, it being centralized is the last of them imo. Having experienced the mess that is go's decentralized dependency management, I'm not sure why anyone would want to replicate it. Putting aside security, availability and mutability is a massive problem, anyone can stop hosting their module, or worse, change an existing published module at any time. Why not take some inspiration from maven ce…

Deno has the best of both worlds, as I see it.

Users who need centralization / QA from their packaging ecosystem can always opt in to a centralized repository.

Re: Deno 1.0

#456
post #404

Earlier quoted context omitted.

That is not enough at all and there are other attacks! I can't belive in 2020 some people still need to be explained why not enforcing https is a terrible thing! For instance, will a lockfile prevent someone from eavesdropping on the download of a modules through http? If so, please kindly tell me how!

https prevents MITM but doesn't prevent the modules being backdoored or otherwise altered at the source. I would prefer https-only, sure, but it doesn't buy you very much security.

Well, diasabling http by default is basically "Internet 101" here.

I don't want to write an full lecture on how many attacks are possible when people don't use https. It has been commmon knowledge for way more than a decade

Re: Deno 1.0

#457

Earlier quoted context omitted.

The whole idea of a URL is that it’s a standardized way of identifying resources in a universally unique fashion: if I call my utility library “utils”, I’m vulnerable to name collisions when my code is run in a context that puts someone else’s “utils” module ahead of mine on the search path. If my utility module is https://fwoar.co/utils then, as long as I control that domain, the import is unambiguous (especially if…

Allow me to provide an extremely relevant example (medium sized code base). About 100 python files, each one approximately 500-1000 lines long. Imagine in each one of these files, there are 10 unique imports. If they are URLs (with version encoded in the URL): - How are you going to pin the dependencies? - How do you know 100 files are using the same exact version of the library? - How are you going to refactor depen…

I believe the long term solution to the issues you raised is import maps: https://github.com/WICG/import-maps

It's an upcoming feature on the browser standards track gaining a lot of traction (deno already supports it), and offers users a standardized way to maintain the decoupling that you mentioned, and allows users to refer to dependencies in the familiar bare identifier style that they're used to from node (i.e. `import * as _ from 'lodash'` instead of `import * as _ from 'https://www.npmjs.com/package/lodash'`).

I imagine tooling will emerge to help users manage & generate the import map for a project and install dependencies locally similar to how npm & yarn help users manage package-lock.json/yarn.lock and node_modules.

Re: Deno 1.0

#458

Earlier quoted context omitted.

> I thought a lot about it, and it seems as secure as node_modules, because anybody can publish to npm anyway npm installs aren't the same as installing from a random URL, because: * NPM (the org) guarantees that published versions of packages are immutable, and will never change in future. This is definitely not true for a random URL. * NPM (the tool) stores a hash of the package in your package-lock.json, and insta…

This is why I think a content addressable store like IPFS would shine working with Deno

That solves this specific problem nicely, although AFAIK IPFS doesn't guarantee long-term availability of any content, right? If you depend on a package version that's not sufficiently popular, it could disappear, and then you're in major trouble.

It'd be interesting to look at ways to mitigate that by requiring anybody using a package version to rehost it for others (since they have a copy locally anyway, by definition). But then you're talking about some kind of IPFS server built into your package manager, which now needs to be always running, and this starts to get seriously complicated & practically challenging...

Re: Deno 1.0

#459
post #454

Earlier quoted context omitted.

How? Say I have `script.ts`. That file exists locally on my computer and the code inside it is trusted (say it was downloaded from a trusted github project via https). It contains import { dependency } from 'http://whatever.url/@1.0.3' with hash '6f09aa686a6263f9e992' or something like that. If an attacker replaces stuff during transfer of the dependency, then the hash won't match (assuming a collision resistant hash…

Oh, I did not get what you meant ^^ well, there are still other issues than integrity with not using https.

Yeah, I'll edit the original comment to clarify that I mean hashes of dependencies.

Re: Deno 1.0

#460

FWIW I tried to install it in a) Windows 10 via PowerShell, success, it took 1 min. b) Linux (WSL1) with curl, 2 min, failed. 3) Linux(WSL1) via cargo.10 min failed with this jewel: > error[E0433]: failed to resolve: use of undeclared type or module `proc_macro` --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/swc_ecma_visit_macros-0.1.0/src/lib.rs:25:20 | 25 | pub fn define(tts: proc_macro::TokenStream…

[deleted]
Post reply on HN