Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

blog.pyodide.org

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#21

Post by rvz »

simonw wrote: post #16
rvz wrote: post #11

Earlier quoted context omitted.

This sounds like a solution looking for an unnecessary security nightmare. Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side. There was a Chrome 0day at the runtime level which allowed untrusted code to run and escape the sandbox in the WASM runtime. This complete worship of WASM (and their runtimes) as this magical silver bullet reminds…

You mean this one? https://theori.io/blog/a-deep-dive-into-v8-sandbox-escape-te... I dunno, one sandbox escape in nine years is a pretty solid track record IMO. Any reason WASM is more dangerous than regular JavaScript?

No. This one. [0].

Even before that, there are several other sandbox escapes that predated the one you posted. [1] [2] and this one [3] can be used to trivially escape its sandbox with either of these vulnerabilities.

So it is not the magical silver bullet one may easily think it is.

[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645

[1] https://blog.ret2.io/2021/06/02/pwn2own-2021-jsc-exploit/

[2] https://issues.chromium.org/issues/40091185

[3] https://phrack.org/issues/72/10_md#article

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#22

Post by ameliaquining »

DarkUranium wrote: post #20
zek wrote: post #19

I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.…

I think one of the issues is that WASM is notoriously hard to generate code for because they decided to use an IR that's fundamentally incompatible with literally any existing native compiler backend's IR (not counting very specialized ones or toy direct-ast-to-machine-code compilers). It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feel…

I don't think the controversy about Wasm's structured control flow has anything to do with any of this? It's not actually difficult to target Wasm in codegen; I've never heard of any real-world compiler project complaining that this was a major burden. ABI concerns are at a different level.

Most low-level IRs don't do structured control flow because most low-level IRs don't need to be translatable to verified-safe machine code in a single fast pass, whereas for WebAssembly that's a core design requirement.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#23

Post by rtpg »

simonw wrote: post #3

I've been looking forward to this for ages! This means we can now take any C/Rust/whatever extension for Python, compile that as a `.wasm` extension, and then load it directly in browser Pyodide projects using: await micropip.install("package-on-pypi") import package_name Here's how to try the new feature out. Visit https://pyodide.org/en/stable/console.html and type: import micropip await micropip.install("pydantic_…

Is there any form of client-side caching that kicks in with all of this flow?

Tbh I don't feel great about people just writing up a bunch of scripts pulling things just on every run.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#24

Post by simonw »

rtpg wrote: post #23
simonw wrote: post #3

I've been looking forward to this for ages! This means we can now take any C/Rust/whatever extension for Python, compile that as a `.wasm` extension, and then load it directly in browser Pyodide projects using: await micropip.install("package-on-pypi") import package_name Here's how to try the new feature out. Visit https://pyodide.org/en/stable/console.html and type: import micropip await micropip.install("pydantic_…

Is there any form of client-side caching that kicks in with all of this flow? Tbh I don't feel great about people just writing up a bunch of scripts pulling things just on every run.

Browser caching works with stuff pulled from PyPI, so it shouldn't get loaded more than once.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#25

Post by hmry »

DarkUranium wrote: post #20
zek wrote: post #19

I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.…

I think one of the issues is that WASM is notoriously hard to generate code for because they decided to use an IR that's fundamentally incompatible with literally any existing native compiler backend's IR (not counting very specialized ones or toy direct-ast-to-machine-code compilers). It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feel…

From what I remember, it was specifically chosen (among other reasons) because of experience with the JVM, where it was difficult to verify bytecode type-safety due to unrestricted jumps and branches.

So the choice was made to put the burden of regularizing the control flow on the compilers at compile time, rather than the browser engine at website load time. Which seems rational to me.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#26

Post by njoyablpnting »

Pyodide is great. I teach coding to kids, mostly creating 2d games with Python, and it was always a pain to manage an environment for each student. Now I have a browser based environment that runs Pygame/Arcade/Pyglet in Pyodide, so the kids can just do everything in the browser, I don't have to worry about Python versions, OS differences, files, etc. As a bonus they can easily publish what they make since it all runs in browser.

They haven't made anything too crazy, but performance is surprisingly good, even wiring in Pymunk for some physics stuff. If they get to the point where it's ever an issue they probably know enough to be working in a real game engine anyway.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#27

Post by csande17 »

ameliaquining wrote: post #22
DarkUranium wrote: post #20

Earlier quoted context omitted.

I think one of the issues is that WASM is notoriously hard to generate code for because they decided to use an IR that's fundamentally incompatible with literally any existing native compiler backend's IR (not counting very specialized ones or toy direct-ast-to-machine-code compilers). It feels like nobody actually consulted actual compiler writers when designing this. I'm sure that isn't true, but it definitely feel…

I don't think the controversy about Wasm's structured control flow has anything to do with any of this? It's not actually difficult to target Wasm in codegen; I've never heard of any real-world compiler project complaining that this was a major burden. ABI concerns are at a different level. Most low-level IRs don't do structured control flow because most low-level IRs don't need to be translatable to verified-safe ma…

http://troubles.md/posts/why-do-we-need-the-relooper-algorit... has a more detailed version of this argument: if WebAssembly had used a CFG as the basis for its control flow, it would have been easier to compile to and easier to efficiently execute/translate while maintaining safety, and maybe GCC would have released a WebAssembly backend by now.

The author alleges that the real reason WebAssembly uses loop/block is because that's how V8 worked internally at the time and Google didn't want to go to the trouble of implementing something different. But more recently V8 has started moving towards CFGs ( https://v8.dev/blog/leaving-the-sea-of-nodes ) so maybe there's hope in the future.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#28

Post by hoodchatham »

apitman wrote: post #10
12_throw_away wrote: post #6

Executing normal python programs inside a cpython vm inside a wasm context inside a javascript process inside a sandbox inside a browser is - genuinely - extremely exciting! (Might as well run the browser inside a container inside a VM while you're at it though.)

I'm sure everyone has seen this by now but just in case: https://www.destroyallsoftware.com/talks/the-birth-and-death...

That video was a major inspiration for me and probably indirectly led to me becoming a Pyodide maintainer.

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#29

Post by nextaccountic »

rvz wrote: post #11
12_throw_away wrote: post #6

Executing normal python programs inside a cpython vm inside a wasm context inside a javascript process inside a sandbox inside a browser is - genuinely - extremely exciting! (Might as well run the browser inside a container inside a VM while you're at it though.)

This sounds like a solution looking for an unnecessary security nightmare. Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side. There was a Chrome 0day at the runtime level which allowed untrusted code to run and escape the sandbox in the WASM runtime. This complete worship of WASM (and their runtimes) as this magical silver bullet reminds…

> Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side.

Sandbox escapes could happen in Javascript too, right? But I don't see people avoiding browsing the web because of that

Re: Pyodide 314.0: Python packages can now publish WebAssembly wheels to PyPI

#30

Post by tancop »

zek wrote: post #19

I've been working on a server-side wasm impl of cpython called boomslang [1] and have been thinking a lot lately about packaging, one of the downsides of my current impl is the need to statically link all c/rust extensions. Its too bad IMO how much of the wasm ecosystem targets/depends on emscripten directly. It'd be interesting to see if a more generic ABI could be provided for non emscripten/js based wasm runtimes.…

wasi 0.3 just came out and its fully component model based with no emscripten specific parts. also supports dynamic linking in the spec but afaik no runtime actually has it implemented in a released version.
Post reply on HN