Import Maps and Node.js

[guybedford]

I'd like to add an agenda item for this weeks meeting to discuss import maps in Node.js.

This came out of the fact that SystemJS is currently looking at merging an "integrity" attribute into the import map to support comprehensive integrity since otherwise this is not possible for lazy dynamic imports, which seems like it may in turn have some cross-over with policies or future directions for policies in Node.js. (systemjs/systemjs#2229)

Modules provide and share capabilities. Capability architectures define the security of platform. Putting security first is crucial to good software and thus putting security first in modules architecture development is crucial. Deferring security related discussions as things to "add at the end" seems risky for the platforms.

While from a browser perspective, import maps have deferred these concerns, for Node.js it could make sense to consider if any of these possible future directions for import maps and related proposals might affect the Node.js application models.

Furthermore, I think it would be useful to discuss if Node.js wants to as a project get involved in the specification process for import maps and related proposals for integrating modules into the platforms.

[zackschuster]

would this live alongside exports in package.json? or in a separate import map file?

[guybedford]

I believe the only suggestion is as a separate file, similarly to Deno. One way of looking at the usefulness / redundancy position of the workflow is something akin to policy where the import map acts like a whole-application lock file guaranteeing the execution, which itself would be generated from the initial resolver algorithm.

…

On Mon, Aug 10, 2020 at 14:54 Zack Schuster ***@***.***> wrote: would this live alongside exports in package.json? or in a separate import map file? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#544 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAESFSQBC65HUTHIKBYPZ4DSABUDDANCNFSM4P2HH4QQ> .

[jkrems]

where the import map acts like a whole-application lock file guaranteeing the execution, which itself would be generated from the initial resolver algorithm.

I think that direction makes a lot of sense. In expect that it might replace package-lock.json rather than package.json. The flow would be that an install process could pull the metadata (e.g. exports and imports) from the top-level and dependency package.json files and generate a single import map from that. But I'm definitely curious where things like integrity would live, especially for otherwise unmapped ("internal"/"intermediate") files or directory exports.

[bmeck]

@jkrems thats essentially what https://github.com/bmeck/node-policy does, in particular the important note here is for policies we defined things to operate on the canonicalized forms for integrity/cascading but request forms for dependency pinning. I don't think import maps currently are attempting to cover the response URL but only request specifiers currently. It is very important to work on the resolved forms to avoid symlink escapes for things unless you want to explain leakages of resolved resources at request locations (see relevant note about attacking a policy scope mechanism having a read privilege ).

[bmeck]

I'd also note for any sizable graph complete up front resolution is costly, at 16k potential edges in a graph (for a small/medium CLI of node-policy dog fooding itself) after multiple attempts to speed things up and be lazier it is still a 200ms hit to startup on a recent laptop. The solution is to use scoping, but that on its own is different in terms of policy vs import maps design. Import maps cascade by default whereas policies have tended toward least authority by default.

[guybedford]

@bmeck that links seems to be private access only. The whole response URL model still is very unfortunate, but worth noting for Node.js at least that it is fully ruled out since resolution is always based on registry URL and we have no response URL model (and hopefully never will).

[bmeck]

@guybedford moved to make the slide public

Per request/response in node terms it is pre-realpathing post-realpathing, this is a general cause of various concerns around path traversal and when the permissions are supposed to be considered. http://capec.mitre.org/data/definitions/132.html has various examples . The same level of workflow considerations have to be applied.

[guybedford]

@bmeck I wouldn't associate realpathing with the request response model, since in Node.js real-pathing is part of the resolve function, there is no fetch / locate separation. Specifically, the request URL is defined as the registry URL, which in Node.js is the real path.

[bmeck]

@guybedford if we implement https and since we deal with --preserve-symlinks we do have a disparate form of canonicalization. If for example you use --preserve-symlinks you can escape a given directory structure since loaders will not be keyed off of canonicalized (realpathed) location. The same is true for redirects on the web but by default the URL is not canonicalized by redirects.

[guybedford]

I would be against an https loader in core implementing responseURL if it ever came to that, I don't think we have an obligation to follow HTML there. --preserve-symlinks is more like --conditions in that it alters resolution for the entire environment.

[bmeck]

@guybedford I'd disagree and don't think we should go against the web cache as specified by WHATWG. I'm in fair disagreement about --preserve-symlinks but thats probably a different issue. I am just stating concerns that need to be documented and figured out.