jupyterlab / jupyterlab-plugin-playground

A dynamic extension loader for JupyterLab
BSD 3-Clause "New" or "Revised" License
47 stars 15 forks source link

There should be a way to verify subresource integrity #30

Open krassowski opened 2 years ago

krassowski commented 2 years ago

Problem

It is not possible to verify SRI integrity of assets served by CDN. There was a previous discussion on it in https://github.com/jupyterlab/jupyterlab-plugin-playground/issues/1.

Proposed Solution

allowCDN setting should accept only-trusted-packages value; if set to such value it only imports with a defined integrity hash should be allowed; those values could be stored as:

   {
      "trustedCDNPackages": {
           "bqplot@0.5.32/lib/index.min.js": "sha384-3PzjY/W0RzwwNNzUX7xM9Yg0AMgf7lNIV9vccrG++xQd7ZniA8z26dhjQa84Whdh"
      }
   }

we could be showing a window with the package code and automatically add SRI to the trustedCDNPackages if user confirms that this is ok.

I attempted to do this for requirejs in 8aa1628fa82a669869233946385834676c996ce0 and reverted in 4cf596b6bd297afb553b3afc21b531c4f1ad6a79 because it did not work reliably.

A lot of code can be reused from the above commits, but we probably should give up on requirejs altogether and use SystemJS which supports semi-unofficial-standard integrity maps (in the proposed format), see https://github.com/jupyterlab/jupyterlab-plugin-playground/issues/1#issuecomment-1008071382.

Additional context

I previously suggested that we could manually check integrity for ESM.sh (in https://github.com/jupyterlab/jupyterlab-plugin-playground/issues/1#issuecomment-1008037242); this is doable but computing hashes is not trivial and requires https secure context in modern browsers or a new dependency; SystemJS already takes care of it so its another argument for going that route.

krassowski commented 2 years ago

I think that my previous attempt failed because at one point the require.js setup stopped working on my branch (fixed in fbc5b398be8779d6ab0adc251a20ec34d10929ca). It should be possible to revive this effort once #28 is merge (i really should stop expanding on the change set there).