Announcing WCGI: WebAssembly and CGI
21–30 of 121 posts
Re: Announcing WCGI: WebAssembly and CGI
#22The amount (and evolution) of acronyms in the WASM space is kinda overwhelming so I might be out to lunch… At the top of the article it says “…compiling them to WASI”, but is that a semantically/technically correct statement? My understanding would be more that it should say something like “compiling them to WASI-compliant WASM” or something. Or can you actually “compile to WASI”
Like when you say "HTTP API" you don't necessarily need to change it to "TCP HTTP API" as it's somewhat implied (although maybe a shitty example, as HTTP is starting to appear over more things than just TCP as of late)
Re: Announcing WCGI: WebAssembly and CGI
#23Next thing you know each wasm assembly will need a package format to ship assets with and have the app server provide common resources to all assemblies, e.g. db connection pools, some notion of security, etc. Replace Wasmer with the a JVM-based app server and WASM assemblies with JVM-bytecode. The big difference is the source language doesn't matter as long as it's able to be run/replaced by WASM bytecode. We're hea…
Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly
Re: Announcing WCGI: WebAssembly and CGI
#24I don't understand. Why not just compile to machine code and use plain old CGI?
Re: Announcing WCGI: WebAssembly and CGI
#25PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…
I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to protect their content.
Otherwise, the WASM-dust at best moves the security boundry to a different service.
Re: Announcing WCGI: WebAssembly and CGI
#26PHP was compiled into WASM, so now you can run PHP apps "as WASM". How is this different from just running PHP, without WASM? Apparently it's faster, but also they make this claim: "Picture running Wordpress and not having to worry about attackers breaking into your system" uh, so, you sprinkled some WASM magic on some code and suddenly several decades worth of security research is obsolete? .....yeah, I'm gonna call…
edit: this was completely wrong, TFA is talking about server side WASM I think the point is that a simple-enough application can be delievered as WASM and run entirely in the user's browser, so there wouldn't be any server-side system to break into? So one could ship e.g. wordpress + db + content in one bundle, and the user would be none the wiser. A wild claim, and probably self-defeating for anyone who needs to pro…
Re: Announcing WCGI: WebAssembly and CGI
#27Earlier quoted context omitted.
Full disclosure, I have only minimal understanding of web assembly, other than using C functions inside a web browser. I run wordpress in a read only docker container, what better security could WCGI bring?
Here are the main differences with the Docker strategy: * If you want it to be usable, you will need to ship it with some mechanism that allows running CGI over http (kind of Apache or Nginx), so your container would be bigger than the Wasmer package * Regarding security: Docker containers needs to rely on hardware virtualization to run securely (via KVM or simlar), aside of a virtualization on the systemcall layer (…
Is wasmer stable and secure enough to be exposed to abuse of the entire Internet?
> your container would be bigger than the Wasmer package
The first Google hit for "docker php nginx" is https://hub.docker.com/r/trafex/php-nginx - they claim their Docker image is 40 MB compressed, whereas Wasmer for amd64 (latest from https://github.com/wasmerio/wasmer/releases) is a 80 MB tar.gz (unpacks to 300 MB tar). Even with larger images, like the `wordpress` image (200 MB), the size is neglible.
> Because of that, Docker containers will have the downside of: being able to run only in one chipset/OS
You probably don’t need to care about architectures other than amd64 and arm64. Both are supported by the trafex/php-nginx and wordpress Docker images.
> (even if you use state of the art for running them, aka Firecracker, you still get 250ms vs Starting a fresh VM for every request doesn’t make sense, so this difference wouldn’t matter in real life.
Re: Announcing WCGI: WebAssembly and CGI
#28Re: Announcing WCGI: WebAssembly and CGI
#29I don't understand. Why not just compile to machine code and use plain old CGI?
Re: Announcing WCGI: WebAssembly and CGI
#30I don't understand. Why not just compile to machine code and use plain old CGI?