Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#188 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

@livenson đang làm issue này rồi.

Từ ngày 13/9/2026.

  • #196 của @livenson — đang mở

Đánh giá

Độ khó
3/5
Thời gian dự kiến
1-2 ngày
Mức phù hợp với người mới
70/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
typescript, wasm
Lĩnh vực
security, web-dev

Hướng nghiên cứu

Bắt đầu trong lib/ghostty.ts, so sánh init() với Ghostty.load(wasmPath?) và defaultPaths của nó. Kiểm tra cách bundle được phát hành và dist/ghostty-vt.wasm được tạo ra, sau đó xem lại hướng dẫn CSP trong README. Được xem là hoàn tất khi init() có thể tải wasm được đóng gói sẵn với connect-src 'self' mà không có lần thử data: bị thất bại, đồng thời có các bài kiểm thử hoặc xác minh được ghi chép cho đường dẫn tải đã chọn.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
TypeScript
Star
3k
Fork
183
Không có pull request nào được merge trong 30 ngày

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của coder/ghostty-web

Tất cả issue của coder/ghostty-web

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.