Do not try loading unknown extensions automatically

[paulkaplan]

This fixes an issue where projects that have experimental extensions will fail to load when run in production scratch. The failure mode is that they just "hang" on the loading screen. Instead, bailing on loading worker extensions (since none are implemented) will result in the project loading actually erroring out, which is handled correctly. Remaining in limbo is the bug.

This fix was recommended by @cwillisf.

I'll admit I'm not the most familiar with this functionality. It seems like it was designed to support a system we did did not (have not?) used yet. This fix does not finish that functionality, it just adds an explicit switch in the code to make it clear that it is not fully implemented.

/cc @ericrosenbaum

[paulkaplan]

Also /cc @kchadha, not sure if you were involved with this part of the extension support infrastructure. I'm not super happy with this fix, mostly because I do not fully understand how the extension worker is intended to be used or to work. For instance, this problem does not impact standalone GUI editors, only the production site, it seems like because the extension-worker.js script is not available on scratch production. Is this intentional? I'd like to take the time to understand this.

[paulkaplan]

@ericrosenbaum @cwillisf I investigated this a bit more. It looks like on scratch production, the static extension worker file is not available (not exactly sure why, possibly webpack config didn't hoist it up the chain). The result is wonky: there is no error associated with calling new Worker("a url that will 404"), at least it doesn't seem like it. So it can't be caught as an error. There is a "handshake" RPC that goes to the worker, but because it is a promise, there is no cancel timeout, so it just hangs in "waiting for a response to the handshake" mode. We could add a timeout to that handshake, which would fix this problem without introducing new logic about whether we allow unknown workers. However, having that functionality available on production scratch seems like a problem, because if we fixed the webpacking and made the worker available, it would then start requesting (possibly arbitrary?) urls when loading projects. So maybe the original fix @cwillisf suggested is the right one. Maybe slightly better would be to make it a VM-level configuration option, and just have scratch-ww disable it?

[apple502j]

@paulkaplan

if we fixed the webpacking and made the worker available, it would then start requesting (possibly arbitrary?) urls when loading projects.

That was how CVE-2020-14000 worked. Because #2476 is merged there should be no problem.

Note that after the fix, scratch-vm cannot load worker extensions when loading projects. sb3.js has extensionURLs map which is just unused. I think it is better to change https://github.com/LLK/scratch-vm/blob/develop/src/virtual-machine.js#L511 to something like

extensionPromises.push(new Promise(resolve => {
    extensionManager.loadExtensionIdSync(extensionID);
    resolve();
});

(this was the original fix i suggested for #2476 btw)

[ericrosenbaum]

@paulkaplan looks like this still needs work. I get the "project failed to load" alert (so the hang on loading screen is prevented), but the editor ends up in a broken state with no sprites and no stage.