The idea of exposing Python via a normal cgi script is terrifying to me
Announcing WCGI: WebAssembly and CGI
81–90 of 121 posts
Re: Announcing WCGI: WebAssembly and CGI
#82Next 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…
You mean in a OCI image, a bit like this? - https://docs.docker.com/desktop/wasm/
and then deployed using Kubernetes? - a bit like this - https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-po...
Re: Announcing WCGI: WebAssembly and CGI
#83Earlier quoted context omitted.
Give us the recap
http://www.astrodigital.org/space/stshorse.html I'd be very leery of trusting the specifics too much. E.g. the reference to "Roman war chariots", which are not a thing the Romans ever used. Snopes entry: https://www.snopes.com/fact-check/railroad-gauge-chariots/
God, I had forgotten about those email FWDs. The old people I know totally abandoned email.
Re: Announcing WCGI: WebAssembly and CGI
#84Earlier quoted context omitted.
I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.
Not just in the past, arbitrary program sandboxing is not possible even today.
Re: Announcing WCGI: WebAssembly and CGI
#85PHP 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…
https://make.wordpress.org/core/2022/09/23/client-side-webas...
(By my colleague Adam!)
I think this experiment becomes interesting thinking about times you really want WordPress to be headless (like demoing a plug-in or theme), but less for serving websites to people. Potentially also useful as a testing development environment.
I was surprised at how fast it is, since it basically becomes an SPA.
Re: Announcing WCGI: WebAssembly and CGI
#86Re: Announcing WCGI: WebAssembly and CGI
#87Earlier quoted context omitted.
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
There was a time when JVM ran in the browsers.
That web application is still in use, in production, today.
Re: Announcing WCGI: WebAssembly and CGI
#88PHP 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…
Compiling a service to wasm to protect it "from itself" (ie from untrusted data) has trade-offs. On the one hand, you lose ASLR and other security features designed for native code. On the other hand, your program becomes immune to stack smashing, so arbitrary code execution becomes a lot harder for an attacker (at least that's my understanding).
And of course WASM won't protect from just regular ol logic bugs like SQL injection or similar.
Compiling things to WASM to make them "more secure" seems bonkers backwards. WASM's priorities are to protect the host, not the guest.
Re: Announcing WCGI: WebAssembly and CGI
#89The 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”
WASI is just WASM outside the browser, it kind of implies what you're saying. It's still WASM, just adhering to a specific interface. 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)