Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

How to bless asset references #247

Open
mikesamuel opened this issue Dec 6, 2019 · 1 comment
Open

How to bless asset references #247

mikesamuel opened this issue Dec 6, 2019 · 1 comment
Labels
future In consideration for the future releases of the API spec tc39
Milestone

Comments

@mikesamuel
Copy link
Collaborator

The TC39 asset reference +(@bmeck @sebmarkbage) separates information about modules from loading of modules.

Ir provides new syntax for [static asset references]:

asset Foo from "foo";
// Now the name Foo is an asset reference object which can be passed to import(...)

and API for dynamic asset references:

let assetReference = import.resolve("./foo" + fileExtension);

It would be nice if Trusted Types could recognize that

  • the "module-reference" in asset Name from "module-reference" is in the same protection domain as import * from "module-reference" when guarding dynamic import.
  • provide a policy function to bless at least one of
    • a dynamic asset reference
    • its underlying module specifier (perhaps before being passed to import.resolve.

import.resolve does not AFAICT, do any security work. No fetching happens. So it seems that import.resolve is not a sink.

@bmeck
Copy link

bmeck commented Dec 6, 2019

I'd note that import.resolve would expose potential resolutions that might be prevented in other contexts.

// name: privileged
// file allowed to resolve 'secret'
export function resolve(foo) {
  return import.resolve(foo);
}
// not allowed to obtain trusted resolution for 'secret'
import resolve from 'privileged';
resolve('secret');

This kind of pattern of delegated importing is used by ecosystem APIs like React.lazy

@koto koto added spec tc39 future In consideration for the future releases of the API labels Mar 2, 2020
@koto koto added this to the v2 milestone Mar 6, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
future In consideration for the future releases of the API spec tc39
Projects
None yet
Development

No branches or pull requests

3 participants