Improve CSP

[amaury1093]

I read some more stuff about CSP:

• onHeadersReceived doesn't work in prod mode with file://. This means that we need to set a <meta> tag for CSP in index.html, which I did. Edit: Created an issue on Fether too, it's a big security risk there.
• removed unsafe-eval everywhere, it's actually not needed by CRA. However, now we cannot run wasm code, so it'll default to the JS one. We should wait for the wasm-eval CSP (maybe in Electron 5?)
• tightened CSP where I could.

After testing, these CSP work in both prod and dev

[amaury1093]

The http here is not needed in prod, and should be overwritten in the onHeadersReceived in dev. However, somehow it doesn't work: https://stackoverflow.com/questions/51969512/define-csp-http-header-in-electron-app#answer-52243138

So we can:

• either add http in prod, which I believe doesn't introduce a large attack surface, and allow CRA hot reloading
• or remove http in prod, but then CRA hot reloading breaks.

[amaury1093]

@yjkimjunior I would like you to try yarn start and yarn package to make sure everything works. Also, in the binary, there shouldn't be any electron warning messages (confirmed working on my machine)

[pmespresso]

@amaurymartiny confirming this works on my machine as well.

Once we bundle the light client though, wouldn't we need unsafe-eval? Especially as it looks like the wasm-eval/wasm-unsafe-eval proposal for Chromium has been very slowly moving toward implementation....maybe.

anderejd/electron-wasm-rust-example#6
WebAssembly/content-security-policy#7

[amaury1093]

Once we bundle the light client though, wouldn't we need unsafe-eval?

No, we bundle the light client inside Electron, and spawn it from the electron process, there's no wasm involved. The day we'll have a light client in wasm (which realistically won't happen in the next 6 months imo), we'll need to enable unsafe-eval