Live data from Hacker News

Announcing WCGI: WebAssembly and CGI

wasmer.io

101–110 of 121 posts

Re: Announcing WCGI: WebAssembly and CGI

#101
post #96

Earlier quoted context omitted.

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

I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?

I meant decent sandboxing on the JVM is not possible, that’s the advantage of WASM.

Re: Announcing WCGI: WebAssembly and CGI

#102
post #58

Earlier quoted context omitted.

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

Does it become harder or easier? #include #include int bad(char* src) { int admin = 0; char buf[2]; strcpy(buf, src); printf("%d\n", admin); return admin; } int main() { if (bad("ADMIN!!!")) { printf("we're admin!\n"); } else { printf("we are not admin\n"); } }

If you’re worried about securing server side resources by hardening the client side, you’re doing something wrong.

At any rate, the example you give is arguably a better case than what we have right now with JS — anyone interested in subverting client side access policies can poke around trivially in the JS globals, they don’t even need to decompile anything, they have a DOM inspector and a REPL to make exploits that much easier to pull off. If security through obscurity is your thing, compiling to WASM could only help.

Again, though, client side shenanigans shouldn’t be of any concern anyway.

Edit: I thought I was replying to the other comment you made within the context of client side execution, but I can touch on that too.

Programming errors (and resulting exploits) aren’t something unique to WASM, and there’s nothing stopping you from using something like Go or Haskell or Rust as a source language, if you want something more safe than C.

Re: Announcing WCGI: WebAssembly and CGI

#103
post #36

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

Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.

Java can be fast and memory efficient. The problem I see with many Java programs is that they're built on top of layers upon layers of frameworks. Web server frameworks on top of multithreading frameworks with database ORM frameworks and microservice frameworks all calling in and out of each other. Stack traces that end up accumulating 30 or 40 calls before actual product code even begins.

Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations.

Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either.

The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.

Re: Announcing WCGI: WebAssembly and CGI

#104

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

Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with th…

Believe a plugin need to be installed first. Fuzzy memory says the JRE install set it up for you.

Re: Announcing WCGI: WebAssembly and CGI

#105

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…

The WASM sandbox is a lot stricter than running native code, or many other VMs (Java/dotnet). The difference seems to be in the design process: most normal VMs are built around the idea of quickly developing and deploying an application that can do everything a native application can do, without having to deal with platform differences. WASM was built around optimizing specific parts of web pages and was explicitly designed NOT to have a huge surface area. By default, you set it up to be little more than "memory goes in, memory comes out" without having to worry about file system restrictions or sockets like you have to with alternative VMs.

I'm not a fan on the way these features are being tacked back onto the runtime, but the approach of having to opt into them make the security boundary a lot more transparent. By disabling the file system (i.e. baking a fake one into memory) you can prevent whole classes of attacks. You won't get surprised by your logging library making network calls (log4j) if your sandbox never even enabled networking in the first place.

I'd much rather see easy and safe alternatives (like using containerization APIs) but there's still no easy way to tell your computer "run this program with a maximum amount of memory, CPU time, no network access and no file system outside this directory" that doesn't come with tons of caveats for preventing escape. For PHP, setting up a secure systemd configuration (more secure than the one that comes with your package manager) can be done, but it's still far from easy.

Re: Announcing WCGI: WebAssembly and CGI

#106

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 code or "running in a sandbox" does not stop attackers from breaking into your system.

Correct - PHP is a scripting language with managed memory, quite different from C. Probably not all, but most WordPress vulnerabilities have to do with issues like sql injection, bad configuration defaults, etc, all in business logic. All of these will continue to exist when compiled to Wasm.

Assuming you actually have access to a database in the first place, while wasmer may have some vendor locked in solutions for it, generally with Wasm you won't get beyond SQLite for the near term.

Re: Announcing WCGI: WebAssembly and CGI

#107

Earlier quoted context omitted.

I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty a…

Well, that's partly why WASM exists. It can be run outside a browser, and is much more performant than using the whole browser. The future is very likely going to consolidate around WASM and WebGPU, regardless of what hardware you're targeting. If you want more performant specs, it will be driven through a public and consensus driven way... there are far too many economies of scale to standardization for it not to be…

Yeah. You’re right. THIS will be the time that open wins. When most peoples primary computing is running an OS developed by one of two companies that have a strong incentive to maintain walled gardens.

Largest /s imaginable.

Your comment is pretty far into LARPing territory.

Re: Announcing WCGI: WebAssembly and CGI

#108
post #83
post #78

Earlier quoted context omitted.

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.

That’s a bit cynical and dickish. Maybe he just read it, found it enjoyable, and remembered it? God.

Re: Announcing WCGI: WebAssembly and CGI

#109

Earlier quoted context omitted.

Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with th…

> but 20 years ago you could run JVM apps in the browser without issues That was definitely not my experience at that time using a linux desktop.

I’m sure that compared to doing anything else on a Linux desktop it was just fine. You made your bed.

Re: Announcing WCGI: WebAssembly and CGI

#110
post #20

Earlier quoted context omitted.

It is incredible how with so much Java hate, the WASM folks are doing their best to replicate everything we had in 2005.

We are not replicating Oracle’s lawyers, sales agreements and non-disclosure policies.

The hate against Oracle is beautiful, when WASM only exists due to politics against PNaCL, and without Microsoft, Google and Apple there is no WASM standard anyway.

All angel companies that do no evil.

Post reply on HN