Open yujin-wu opened 2 years ago
Thanks for the PR! It would be great to fix the CSP issues! I don't currently have time for an in-depth review, but a couple things which jump out at me are:
window.__regl_codegen_cache
will work since window
may not exist. I think any caching would need to be scoped to the specific regl instance.crypto
isn't currently handled correctly by rollup. I see a warning like this:
Treating 'crypto' as external dependency
No name was provided for external module 'crypto' in options.globals – guessing 'crypto'
with the result that dist/regl.js
tries to call a function require
to locate it, which doesn't exist:
(function (global, factory) {
typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory(require('crypto')) :
typeof define === 'function' && define.amd ? define(['crypto'], factory) :
(global.createREGL = factory(global.crypto));
}(this, (function (crypto) { 'use strict';
A way this has been handled in the past was to write a browserify transform which could be run to transform a dynamic call into a static call. See, for example cwise-transform.js which replaces the entry point to replace dynamic calls with code generation to static calls with the generated code. Unfortunately, the ecosystem is fragmented and browserify transforms can cause lots of headaches with various bundlers.
If anything though, I think it'd be maybe preferable to replace interaction with a global window.__regl_codegen_cache
with proper methods like regl.getCachedCode()
and regl.preloadCachedCode()
, after which you could load it however you like.
Ah, I think static-module was the module which replaces module usage with inline expressions. Plotly includes it via brfs
, though I'm not sure if it's actively used already. https://github.com/plotly/plotly.js/blob/master/package-lock.json#L1156
Thanks for taking a look!
I have added the cache to window before because I thought maybe applications have libraries that instantiate regl itself which wasn't accessible to the application. But alas I haven't seen an example of that, and it is nicer to keep it contained so as you've said I've changed that now.
I didn't even realize the crypto issue until you mentioned it, because the resulting code did happen to work wherever web cryptography existed :P. But yeah it ought to be fixed - I am still replacing it with a dependency-free safe hash function (hopefully lighter than sha256). I am still considering whether using an attackable hash/digest function to index cached code is a security concern here, if so I may end up having to include a crypto library just for this purpose.
So great that this is being worked on, scattergl
working with a strong CSP will be awesome!
Issue
https://github.com/regl-project/regl/issues/638
unsafe-eval
. This change allows developers to pre-generate shaders for their apps and make them CSP compliant.Changes
This makes it possible for developers to create CSP compliant apps using regl, roughly by:
__regl_codegen_cache
, and save into application source.__regl_codegen_cache
. Regl will avoid codegen for those functions.Impact on performance