Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

CSP: wasm loads via data: URI fetch (blocked by connect-src 'self') and init() offers no wasm path override

Aperta
  • Qualcosa non va?
#188 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@livenson ci sta già lavorando.

Dal 13/9/2026.

  • #196 di @livenson — aperta

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
70/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
typescript, wasm
Ambito
security, web-dev

Direzione di ricerca

Inizia in lib/ghostty.ts, confrontando init() con Ghostty.load(wasmPath?) e i relativi defaultPaths. Verifica come vengono prodotti il bundle pubblicato e dist/ghostty-vt.wasm, quindi esamina le indicazioni CSP nel README. Il lavoro è completato quando init() può caricare il wasm incluso con connect-src 'self' senza un tentativo data: che fallisce, e sono presenti test o una verifica documentata per il percorso di caricamento scelto.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Context

Same evaluation as #187 — considering ghostty-web for the SSH/Kubernetes terminals in Cloud Foundry Stratos, this time measuring startup under a Content-Security-Policy. Functionally the probe went well: rendering, canvas selection, and the fit() → onResize resize contract all worked. What did not survive is wasm loading under a strict-but-ordinary policy. Full measurements are recorded here.

What happens under connect-src 'self'

Policy used (a fairly common strict baseline, and Stratos's shipped default):

default-src 'self'; script-src 'self'; connect-src 'self'; ...

With [email protected], await init() fails in three steps:

  1. The first candidate the loader tries is the module URL — but in the published bundle the wasm is inlined as a base64 data: URI, so the module-relative URL is a data: URL. fetch() of a data: URL is subject to connect-src, and 'self' blocks it. One CSP violation is logged per load.
  2. The fallbacks ./ghostty-vt.wasm and /ghostty-vt.wasm resolve against the page, not the module — 404 unless the deployment happens to serve the wasm at the document root.
  3. init() takes no arguments, so there is no way to point the loader at the real file (which does ship in dist/ghostty-vt.wasm).

Result: Error: Failed to fetch WASM: 404 Not Found, and the terminal cannot start at all under a policy that plain xterm.js runs under.

Reading lib/ghostty.ts, the capability already exists one layer down: Ghostty.load(wasmPath?) accepts an explicit path and defaultPaths puts the module-relative URL first — the gap is only that init() does not expose it, and that bundling turns the module-relative default into a data: URI.

Suggestions

  1. Plumb the path through init() — init(wasmPath?: string) or init({ wasmUrl }), forwarding to Ghostty.load(). This alone unblocks any CSP-constrained embedder, and it looks like a one-line change given load() already takes it.
  2. Publish the bundle without inlining the wasm, so the module-relative candidate resolves to the real dist/ghostty-vt.wasm file — or at least order the same-origin candidates before the data: fallback. Beyond CSP, the inlining also carries ~560KB of base64 in the JS bundle for a 413KB binary that ships in the package anyway, and even when loading eventually succeeds by another route, the data: attempt logs a CSP violation on every page load, which is noise for anyone running violation reporting.
  3. A docs note on 'wasm-unsafe-eval' — once the fetch succeeds, WebAssembly.compile() still requires script-src to include 'wasm-unsafe-eval'. That one is inherent to running wasm under CSP rather than anything ghostty-web can fix, but a line in the README would save the next embedder the discovery cost.

For what it's worth, with the wasm served at the document root and 'wasm-unsafe-eval' added, everything downstream passed cleanly in our probe — zero style violations, correct rendering, selection and resize all good. The loading path is the only blocker.

Lingua principale
TypeScript
Stelle
2.9k
Fork
182
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di coder/ghostty-web

Tutte le issue di coder/ghostty-web

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.