Live data from Hacker News

Announcing WCGI: WebAssembly and CGI

wasmer.io

81–90 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#81
This looks good, I'd been thinking about putting my little Python program that prints a random line from a textfile onto my Apache server for the internet to enjoy, this ought to enable it nicely. Where would be best to look for examples?

The idea of exposing Python via a normal cgi script is terrifying to me

Re: Announcing WCGI: WebAssembly and CGI

#82
post #7

Next 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…

> Next 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.

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

#83
post #78
post #76

Earlier 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/

Nice, so dude was actually just reciting an email FWD he studied to sound interesting.

God, I had forgotten about those email FWDs. The old people I know totally abandoned email.

Re: Announcing WCGI: WebAssembly and CGI

#84
post #23

Earlier 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.

Exactly, yet everyone pretends wasm is the exception for some reason...

Re: Announcing WCGI: WebAssembly and CGI

#85

PHP 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…

It’s already been done!

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

#87
post #11

Earlier 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.

I recall around 2010 or so, when a company I worked for was creating a new, rather ambitions, web application. I had to argue against using Java Applets in favor of standard web technology for several components. Thankfully I won that battle.

That web application is still in use, in production, today.

Re: Announcing WCGI: WebAssembly and CGI

#88

PHP 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).

The fact that the address space starts at 0x0 comboned with no ASLR seems like some pretty major regressions in security. Nearly all SIGSEGV crashes just became memory corruption bugs, for example. That's huge.

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

#89

The 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)

WASI is also WASM inside the browser :), since there's a js/wasm conformance of the interface: https://www.npmjs.com/package/@wasmer/wasi
Post reply on HN