cache corruption side channels: plugins needs to be taken into account when deriving cache keys about broccoli-babel-transpiler

[stefanpenner]

Just a note, although logged here (for posterity) this isn't a bug in this repo, rather consuming add-ons must correctly calculate their own cache key. They can do so using many mechanisms, one of which could be using hash-for-dep module. If they do not do this, they must not opt-in to the persistent cache, if they do so stale reads may occur.

[stefanpenner]

This is most likely a mix of:

• documentation that may need to be added
• an example of how some subclasses are not implemented correctly.

[rwjblue]

@stefanpenner - I am not sure what you are actually referring to. What packages subclass this broccoli filter? Most simply consume it.

Also, broccoli-babel-transpiler is the only thing that is actually aware of the plugins being used. How would some random package that is simply consuming broccoli-babel-transpiler change the babel transpilers internal cache key?

[stefanpenner]

Thanks for pointing that out.

[dfreeman]

Talked briefly with @rwjblue about this in Slack — as a concrete example of where this can bite people, templates compiled via ember-cli-htmlbars-inline-precompile aren't invalidated when the template compiler changes. This means when running ember-try with config spanning different compilers, some scenarios are doomed to fail.

With this repo, which runs a simple integration test against ember-canary and ember-alpha, whichever scenario runs first will pass, and the other will fail due to the compiled template being in an unexpected format.

[Turbo87]

@rwjblue can we consider this fixed/implemented now with the latest set of changes?

[rwjblue]

I think so. There may still be specific bugs, but I think we can likely close this...