Lann

> any sense for the cost and pain? Relatively high. We'd essentially need to fork/recreate a significant chunk of wasmtime-wasi.

Some relevant lines from the crash report: ``` Process: spin [41590] Parent Process: spin [41588] OS Version: macOS 12.7.5 (21H1222) Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) ``` Spin re-executes...

Oh this is also interesting: The crash report gives the binary path as `/Users/USER/*/spin`; I assume `USER/*` is just crash report anonymization, but notably this is under `/Users/`. @jandubois's "remove...

> not immediately, but when a connection to localhost:3000 is made. Interesting. I'm not familiar with macOS code signing; is there some capability bit that needs to be turned on...

That all makes sense to me. Wasmtime as a runtime definitely requires execution of unsigned code and it doesn't do JIT compilation in any sense that would matter for `mmap`;...

I think this conversation has been superseded by https://github.com/WebAssembly/wasi-cli/issues/65 and https://github.com/WebAssembly/wasi-cli/pull/82.

We have something a bit along these lines in `spin doctor`: https://github.com/fermyon/spin/blob/967fdf368612478cef176bccc491faffad680050/crates/doctor/src/rustlang/target.rs#L145-L146

I don't see any problem with the given snippet; percent-encoding _should_ be performed on paths before interpreting. There might be issues with `/` in some environments but I'm pretty sure...

It might make sense to disallow `..` as a path component - while WASI impls are _supposed_ to prevent traversing out of a mounted directory like that there really isn't...

> note this cannot be used as a general purpose replacement, since it breaks other scenarios. Could you say more about this? I guess it could be a backward-incompatible change...