Recursive fastbootDependencies not discovered

[ef4]

It does not appear possible to use (for example) ember-network in an addon, because its fastbootDependencies configuration is not discovered by the top-level consuming application.

As a workaround you can add the appropriate fastbootDependencies and dependencies at the top level.

[rwjblue]

You could argue that from a security perspective have some explicit opt-in in he consuming app is good, but having to dig around in all your deps and manually roll things up definitely doesn't feel like a great solution.

One possible avenue to satisfy both concerns would be to require the addon that is being consumed in fastbootDeps and to recurse from there.

[ef4]

My understanding is that fastbootDependencies exists not to protect against addon authors, but to minimize the amount of code accessible inside the fastboot VM that could be used by somebody who finds an XSS (which becomes server RCE in fastboot).

Addon authors can run arbitrary code during the build step and monkey patch whatever they want, bypassing fastbotDependencies.

[tomdale]

@ef4 Yes, I'd like to find time to revisit the entire system. I think it may be possible to track the call site that require() is coming from and do something smart. So for example, if we can tell that a call to FastBoot.require() is coming from liquid-fire/lib/some-file.js, we would know to use the Liquid Fire whitelist. This makes things more robust and more secure, since instead of a global whitelist, you'd have a per-package one.

[kratiahuja]

I think we may not even need to have fastbootDependencies or whitelisting may not be needed with the new updateFastBootManifest hook that ember-cli-fastboot exposes.

[nickschot]

I just ran into this issue. Is there a preferred way to solve or work around this?