14 ms·

This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a sc

This is why JS runtimes should add the ability to set permissions on a per-module basis. Deno is a step in the right direction by requiring permissions for a script to be specified (e.g. deno run --allow-read --allow-net myscript.ts), but the permissions are global for the entire script and can't (yet?) be configured differently for each module / dependency.

cxr 5y ago
Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app." Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming? 1. https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java... 2. https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936 3. https://news.ycombinator.com/item?id=24494434 https://news.ycombinator.com/item?id=24494434 4. https://news.ycombinator.com/item?id=17165784 https://news.ycombinator.com/item?id=17165784
- binarynate 5y ago
  JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.
  - cxr 5y ago
    The runtime environment of the application itself is a separate matter from the environment needed during the fetch-and-configure phase for the modules that the application depends on. This malware was lurking in an auto-executing script that runs upon merely trying to fetch the module. Under the regime that I outlined, malicious actors would be forced to try doing their dirty work within the module's business logic itself, which is far easier to mitigate—for example, with a policy where no code gets merged into the application without undergoing review, whether it is written by a third-party or someone on your team. In spite of all the craziness that the 2010s led to with the rise of specialized package registries trying to recreate CPAN (often erroneously called "language package managers") and giving the illusion that there is such a thing as a free lunch, we're going to have to eventually deal with reality and accept that this is the only reasonable way to approach software development for the stuff that we need to rely on (and that no amount of trying to sweep the problem under the rug with references to Trusting Trust will make the counterargument a sound one).

cxr 5y ago

Alternatively, JS programmers should exhibit less contempt for the standardized, sandboxed runtime that JS was originally created to target: the Web browser. What's nuts is that any of these projects (whether they be single components, larger utilities, or full-blown apps) require a build step that involves anything more complicated[1] than a single machine-readable document in the web browser's native file format and that sits alongside (or in place of[2]) the project README. With so many programmers writing code for the express purpose of making digital documents with behavior dynamic enough to trick you into thinking that the page you have open is really an app, no one in the community with any clout ever stops and says, "Gee, since we're at it, maybe we ought to take this tech that enables us to securely run code on demand and focus it on the goal of allowing other programmers to configure all these modules that we're sharing with one another, or to handle the finishing step of a collection of modules that make up a given app." Then again, that would presume that any of the stuff that this industry engages in is actually meant to solve any problem, rather than creating a neverending supply of them in order to justify the paychecks being written and the egos they're feeding. If stuff's not laughably overengineered to the point of constantly breaking for no good reason[3], does it even count as "real"[4] programming? 1. https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java... 2. https://news.ycombinator.com/item?id=28407936 https://news.ycombinator.com/item?id=28407936 3. https://news.ycombinator.com/item?id=24494434 https://news.ycombinator.com/item?id=24494434 4. https://news.ycombinator.com/item?id=17165784 https://news.ycombinator.com/item?id=17165784

binarynate 5y ago
JS programmers don't have contempt for browsers, it's just that server runtimes like Node and Deno serve a different purpose. A browser isn't the right tool for running a server application or a command line program. If you want a server runtime that behaves more like a browser, though, check out Deno.
- cxr 5y ago
  The runtime environment of the application itself is a separate matter from the environment needed during the fetch-and-configure phase for the modules that the application depends on. This malware was lurking in an auto-executing script that runs upon merely trying to fetch the module. Under the regime that I outlined, malicious actors would be forced to try doing their dirty work within the module's business logic itself, which is far easier to mitigate—for example, with a policy where no code gets merged into the application without undergoing review, whether it is written by a third-party or someone on your team. In spite of all the craziness that the 2010s led to with the rise of specialized package registries trying to recreate CPAN (often erroneously called "language package managers") and giving the illusion that there is such a thing as a free lunch, we're going to have to eventually deal with reality and accept that this is the only reasonable way to approach software development for the stuff that we need to rely on (and that no amount of trying to sweep the problem under the rug with references to Trusting Trust will make the counterargument a sound one).