Repository navigation
refactor: use github.com/go-webengine/esbuildsandbox instead of a local copy - #83
Merged
Merged
Conversation
…al copy The ResolveDir sandboxing fix (engine#65) is a genuinely reusable pattern: any Go program driving evanw/esbuild's pkg/api through a plugin has the same exposure — a glob-shaped dynamic import bypasses OnResolve/OnLoad entirely and resolves against ResolveDir on the real filesystem, no matter how thorough the plugin's own sandboxing is. Extracted it into its own package (github.com/go-webengine/esbuildsandbox, v0.1.0) rather than leaving it siloed here, with its own README explaining the vulnerability and a self-contained regression test that drives a real api.Build and proves it (confirmed to time out walking real "/" when reverted). modules.go now calls esbuildsandbox.ResolveDir() at all three call sites instead of the local esbuildSandboxResolveDir()/esbuildSandboxOnce/ esbuildSandboxDir, which are deleted. Removed the now-redundant TestEsbuildSandboxResolveDirIsIsolated (the shared package tests that itself, with 100% coverage) but kept TestModuleGlobImportDoesNotWalk- RealFilesystem — it is integration-level on purpose, proving this engine's OWN plugin wiring actually uses the shared sandbox at every call site, not just that the sandbox itself is safe in isolation. No behavioural change: same directory-creation logic, same memoization, same fallback. Verified live against developer.mozilla.org (~550ms, matching the fix's original numbers) and the full test suite.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
ResolveDirsandboxing fix (#65) is a genuinely reusable pattern: any Go program drivingevanw/esbuild'spkg/apithrough a plugin has the same exposure. Extracted it into its own package,github.com/go-webengine/esbuildsandbox(v0.1.0), rather than leaving it siloed here — its own README explains the vulnerability, and it has a self-contained regression test driving a realapi.Build(confirmed to fail/time out when reverted to"/").modules.gonow callsesbuildsandbox.ResolveDir()at all three call sites; the localesbuildSandboxResolveDir()/esbuildSandboxOnce/esbuildSandboxDirare deleted.Removed the now-redundant
TestEsbuildSandboxResolveDirIsIsolated(the shared package tests that itself, 100% coverage) but keptTestModuleGlobImportDoesNotWalkRealFilesystem— integration-level on purpose, proving this engine's own plugin wiring actually uses the shared sandbox everywhere, not just that the sandbox is safe in isolation.Test plan
go test -short ./...— full suite green.go vet ./...clean;dom/css/layout/paintcoverage floors all still met.