GSoC'22 - Proposed methodologies for enabling `contextIsolation`
Hey team,
Thanks for having me as a part of GSoC'22 program where I will be refactoring fiddle to latest security standards by enabling contextIsolation and thus removing the Node environment from the renderer process.
Here's a high-level description of the project and I will also be listing out the proposed methodologies to tackle the same (link to my proposal)
-
[x] Migrating away from Parcel bundler - This is the preliminary task before starting off with the actual project. In short, the problem arise because parcel requires the Node environment to be present in the the renderer process while bundling any Electron application due to it's HMR configuration.
Plan - Hence, I will be removing parcel bundler and add webpack to the Electron forge configuration for the bundling process to take place. I will be following as mentioned in the docs! -
[x] Moving
ipcRendererManagerto preload scripts - As the renderer process is now rid of the Node environment, the event emitteripcRendererwouldn't be available due to lack of importing Electron modules.
Plan - That's why, I will be moving and refactoring theipcRendererAPI to preload scripts and it's functions like -send/invokewill be safely exposed to the renderer process (available using thewindowobject) -
[x] Integrating
fiddle-core- Currently, fiddle-core already has the right set of APIs which help to download, manager, bisect and run fiddles. It also provides such APIs which can be integrated within fiddle to de-duplicate similar functionalities. Not only this, but issue #644 will also be tackled which will reduce the storage of built electron in the client's machine.
Plan - Thus, I will be integrating fiddle-core into fiddle's main process and will call such APIs using the IPC event from the renderer to the main process and back (Basically, aninvokecall) -
[ ] Refactoring Node calls to
IPCevents - Finally, the remaining Node APIs have to be refactored as well which are present throughout the renderer process. These Node APIs can be either present in React components OR are used in functions in the renderer process.
Plan - The Node APIs will be migrated to the main process and later called using theinvokecall from the migratedipcRendererManagerpresent in preload scripts. Here's the rough list having the functions/APIs to migrate -
Hence, I believe that the whole project can be broken down into above listed 4 sub tasks. Also, with each tasks, I will be fixing its jests tests and React tests!
That's it from my side! Let me know if I missed something or a specific task can be handled properly with better methodology than what is listed.