31–40 of 73 posts
Wuffs is cool, but you can get similar results writing normal C library code, compiling it into a .wasm binary via Clang, and then running the .wasm binary through the `wasm2c` tool of the WebAssembly Binary Toolkit [0]. I personally prefer this method, although Wuffs will usually produce faster code. [0]: https://github.com/WebAssembly/wabt/tree/44837a7236e85c048de...
Earlier quoted context omitted.
So, there's actually no particular reason and if somebody cares to write one then yup, TIFF codec in WUFFS would in fact be safer and faster than your uh, approach.
One does not rely on the persistent competence of the coders, and will tell you when something has gone wrong. And walking a binary object store to ban problem users is not always necessary... depending what you are doing. Most other approaches makes the same predictable assumptions: https://en.wikipedia.org/wiki/List_of_cognitive_biases Despite popular belief, shitty design does not usually get better in another lan…
Have you been imagining that sandboxes are some sort of fairy dust we just stumbled onto one day, supernatural in nature and not, in fact, just software written by people you're hoping are competent and haven't left any holes?
Wuffs is cool, but you can get similar results writing normal C library code, compiling it into a .wasm binary via Clang, and then running the .wasm binary through the `wasm2c` tool of the WebAssembly Binary Toolkit [0]. I personally prefer this method, although Wuffs will usually produce faster code. [0]: https://github.com/WebAssembly/wabt/tree/44837a7236e85c048de...
It is not obvious to me why this should guarantee safety.
[1]: https://github.com/WebAssembly/wabt/issues/2289#issuecomment...
Can Wuffs provide stronger safety guarantees than techniques like WasmBoxC? My understanding is that compiling unsafe C to WASM and back would also guarantee safety with respect to buffer overflows, integer arithmetic overflows and null pointer dereferences. It’s nice not annotating code to explicitly prove invariants to the compiler like you would in say Wuffs or Rust, but I suppose that’s what limits performance.
What seems nice about wuffs is that it has no side effects and a clear project scope. Deserialization is so riddled with severe issues that it does kind of warrant its own DSL. OTOH, some legacy formats will probably never be ported.
Earlier quoted context omitted.
One does not rely on the persistent competence of the coders, and will tell you when something has gone wrong. And walking a binary object store to ban problem users is not always necessary... depending what you are doing. Most other approaches makes the same predictable assumptions: https://en.wikipedia.org/wiki/List_of_cognitive_biases Despite popular belief, shitty design does not usually get better in another lan…
Wait, you believe that somehow one of these approaches doesn't rely on competence from programmers? How do you figure? Have you been imagining that sandboxes are some sort of fairy dust we just stumbled onto one day, supernatural in nature and not, in fact, just software written by people you're hoping are competent and haven't left any holes?
Or put another way, the available attack surface of a bare-minimum fixed environment is much easier to auto-audit, than a pile of daily permuted binaries and self-delusion approach. i.e. if it fails to behave in an expected way, or is modified in any way... the host audit process doesn't have to care why or how it is broken to maintain a service queue as the guest is culled.
Perhaps I am wrong about exchanging 15% of raw performance for reliability, but things can get complicated with licenses and multiple OS specific platforms.
You seem to be getting emotional about this subject, presenting secondary and tertiary straw-man arguments. So I'm going to go eat some Cheese Goldfish crackers... and just agree that your beliefs are interesting.
Have a fantastic weekend... =3
Wuffs is cool, but you can get similar results writing normal C library code, compiling it into a .wasm binary via Clang, and then running the .wasm binary through the `wasm2c` tool of the WebAssembly Binary Toolkit [0]. I personally prefer this method, although Wuffs will usually produce faster code. [0]: https://github.com/WebAssembly/wabt/tree/44837a7236e85c048de...
Does anyone know of a tool that can do this for PDFs instead?
There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions to voluntarily embed machine and serial hash watermarks. To be clear: formats like pdf, ps, webp, svg, and tiff are so badly implemented in some ecosystems... they can't _ever_ be assumed safe input formats. Thus, at some point people need to spin up an actual…
Earlier quoted context omitted.
Nigel has said that emitting "unsafe" Rust is a reasonable thing for a hypothetical WUFFS 1.0 to be able to do as an alternative to C. As with good "unsafe" Rust written by humans WUFFS would know exactly why what it's doing is fine, it's just that the Rust compiler can't necessarily see that, hence the need to label it "unsafe". Today C makes most sense given the WUFFS language is still in flux. [Edited to fix a ser…
What would be the primary benefit of emitting Rust rather than C? Both would be considered safe (assuming Wuffs generates correct code), and Rust could access the C code via FFI. Is there something I’m missing?
Earlier quoted context omitted.
There are PDF readers that do not support the scripting format extensions. Note this does not prevent unscrupulous companies abusing dominant market positions to voluntarily embed machine and serial hash watermarks. To be clear: formats like pdf, ps, webp, svg, and tiff are so badly implemented in some ecosystems... they can't _ever_ be assumed safe input formats. Thus, at some point people need to spin up an actual…
WUFFS is provably safe - that's the whole schtick. If a WUFFS kernel exists, you can assume it is safe. If it's not proven safe, it doesn't compile. The reason everyone doesn't program in WUFFS is that you have to write a proof that your kernel is safe, which takes a very very very long time.
Wuffs is cool, but you can get similar results writing normal C library code, compiling it into a .wasm binary via Clang, and then running the .wasm binary through the `wasm2c` tool of the WebAssembly Binary Toolkit [0]. I personally prefer this method, although Wuffs will usually produce faster code. [0]: https://github.com/WebAssembly/wabt/tree/44837a7236e85c048de...
How much faster (say, for something like an image codec)
Even if I told you some of the numbers I’ve seen in my experiments and usage, it wouldn’t be wise to trust them or let them taint your opinion.