|
|
|
|
|
by aseipp
1539 days ago
|
|
In the case of NPM consumers of wasm libraries, it often isn't realistic option "as-is", since they won't have the toolchain needed to build the code. Rust is a lot more well oiled than C/C++ in this regard but it's a bit of a hassle to line things up and keep things reliable and reproducible. (Good luck if the blob is not only C/C++ but uses 3rd party dependencies on top of that, which often require even more hurdles). If you don't use the pre-built blob you'll often have to 'insert' it otherwise into the library, somehow, which is its own chore. So it's all a bit chicken and egg at some level. Now, it's not like a lot of these packages ever followed best practices in this regard (I'm reminded of many Ruby, Python, JS packages that love to ship random .so files, and often do it incorrectly) but it is what it is. That said I generally agree with the premise, and even with sandboxing you should vet dependencies like these where appropriate if you can. A good example of this is something like an image decoder versus a database library (both of these being real scenarios; e.g. using a pure-Rust implementation of some SQL protocol.) The first one I probably wouldn't worry too about much, you're just giving it pixels in and getting pixels out. But the second one is likely worth a bit of scrutiny since it interfaces directly with a sensitive component. |
|