Content-Security-Policy CSP regressions: `.cast`, `.pdf`

[silverwind]

asciicast

Regression from #37232. To reproduce:

• Upload a .cast file into repo (ASCIICast)
• Open file view in Firefox, it does not load and browser logs this error:

Content-Security-Policy: The page’s settings blocked WebAssembly (script-src) from being executed because it violates the following directive: “script-src * 'nonce-a7a188e55b1913099d55c3221896d920'” (Missing 'wasm-unsafe-eval' or 'unsafe-eval')

And this one:

Uncaught (in promise) CompileError: call to WebAssembly.instantiate() blocked by CSP
    __wbg_load core-DnNOMtZn.js:286
    __wbg_init core-DnNOMtZn.js:392
    init core-DnNOMtZn.js:433
    async* core-DnNOMtZn.js:2582

The solution is to move the asciicast render to iframe, but the current framework doesn't work.

Because iframe srcdoc inherits the parent page's CSP.

To fix the problem: the iframe window shouldn't not use parent windows' CSP

external pdf

If external render outputs pdf binary content, it is also broken. srcdoc doesn't work for PDF

To reproduce:

[markup.in-iframe]
ENABLED = true
FILE_EXTENSIONS = .in-iframe
RENDER_CONTENT_MODE = iframe
RENDER_COMMAND = cat /path/to/file.pdf
RENDER_CONTENT_SANDBOX = disabled

[wxiaoguang]

Should move it to the iframe too

[wxiaoguang]

BTW: no need for 1.26

Can fix it for 1.27 only in the future

[silverwind]

Yes, 1.26 has no CSP (for good reason 😆)

[silverwind]

Another CSP issue on iframed swagger documents seen in Firefox during testing of #37233

Edit: actually no, this is SOP, not CSP. Error seems benign.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at
http://localhost:3500/silverwind/symlink-test/render/branch/master/openapi.json?gitea-is-dark-theme=true&gitea-iframe-
id=gitea-iframe-46&gitea-iframe-bgcolor=rgb(22%2C+23%2C+24). (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 200.

May or may not be related to this Chrome error:

Unsafe attempt to load URL http://localhost:3500/silverwind/symlink-test/render/branch/master/openapi.json?gitea-is-dark-theme=true&gitea-iframe-id=gitea-iframe-46&gitea-iframe-bgcolor=rgb%2822%2C+23%2C+24%29 from frame with URL http://localhost:3500/silverwind/symlink-test/render/branch/master/openapi.json?gitea-is-dark-theme=true&gitea-iframe-id=gitea-iframe-46&gitea-iframe-bgcolor=rgb%2822%2C+23%2C+24%29. Domains, protocols and ports must match.

[silverwind]

On-topic here. unsafe-eval is a very common requirement for JS dependencies unfortunatly. We should first check if wasm-unsafe-eval is enough for our dependencies or whether unsafe-eval is truly the only way. Maybe there is even a way with CSP to fetch certain scripts with a different CSP.

Best do do an AI review over all dependencies for what CSPs they need.

[wxiaoguang]

But we don't need any CSP in the iframe. Just let the renders freely do what they want.

That's also why I set our CSP in html header (only for main site), but not in HTTP header.

[silverwind]

Ah, I understand, by iframing it, we avoid CSP issues for renderers. Makes sense.

Still would review all other first-party JS can work without unsave-eval, maybe Vue needs it.

[wxiaoguang]

maybe Vue needs it.

No, Vue doesn't need it. I have cleaned the Vue compiler years ago (moved every component to SFC)

https://github.com/go-gitea/gitea/pulls?q=is%3Apr+refactor+vue+sfc+is%3Aclosed+author%3Awxiaoguang

And closed this one: Branch selector disappear immediately (Uncaught EvalError: 'unsafe-eval' is not an allowed) #19851

[silverwind]

So Vue works compiler-less currently? I wasn't aware, nice.

[silverwind]

Should move it to the iframe too

srcdoc iframes inherit the parent page's CSP. Only a sandbox iframe does not.