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

Wuffs: Wrangling Untrusted File Formats Safely

github.com

Post reply on HN
Print view View original

21–30 of 73 posts

Re: Wuffs: Wrangling Untrusted File Formats Safely

#21

Post by tialaramex »

Joel_Mckay wrote: post #18
tialaramex wrote: post #12

Earlier quoted context omitted.

I worked with TIFF pretty extensively, it's a mess but I don't see why a WUFFS TIFF codec can't be fine. What makes you say you need "an actual VM to transcode" a TIFF ?

The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustaina…

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.

Re: Wuffs: Wrangling Untrusted File Formats Safely

#22

Post by Joel_Mckay »

tialaramex wrote: post #21
Joel_Mckay wrote: post #18

Earlier quoted context omitted.

The complex formats of tiff and tga specifications makes it nearly impossible to span all the edge-cases with unit-tests. A VM can be in a known-state snapshot, process pre/post signature logged/compared with a scripted debugger, and binary input/output stripped of non-compliant metadata/blobs at each stage of the pipeline if the process behaves as expected. I've yet to find a better method than Honeypots to sustaina…

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 language. Rather, people just feel more confident it isn't shit anymore.

I have yet to see evidence to the contrary. =3

Re: Wuffs: Wrangling Untrusted File Formats Safely

#23

Post by jszymborski »

timschmidt wrote: post #15
jchw wrote: post #8

Earlier quoted context omitted.

Do you ever need a JS interpreter to parse a PDF? That's horrifying. I understand PDF has a bunch of limbs, but I always assumed the JS stuff was at least separate from the parsing. (I am familiar with the PDF format at a lower level but I never touched any of the weird features.)

I wrote an SVG that's all javascript, no elements. All the graphics are generated dynamically at runtime by the javascript. It's SVG standards compliant, but only opens correctly in browsers, not in inkscape or other desktop publishing apps. I work a lot in OpenSCAD, and had a need to design some custom graph paper. So I found the subset of SVG which was similar to OpenSCAD. :)

Frankly, I wouldn't begrudge a website for not correctly parsing an svg I composed entirely with javascript.

It's annoying you can't just "flatten" or "bake" such an svg like yours into one composed entirely of elements (unless one exists?)

Re: Wuffs: Wrangling Untrusted File Formats Safely

#24

Post by Ono-Sendai »

Wuffs is great. I use it in Substrata (https://substrata.info/) for loading PNGs. It is both faster and safer than LibPNG. It's something around 2x faster than LibPNG in my tests (depending on the PNG file), see timings here: https://github.com/google/wuffs/issues/13#issuecomment-17325...

So generally Wuffs is great and you should use it to decode your PNGs. There are some downsides: not all of the obscure bit depths and formats that PNG supports are loaded as-is, some are converted to more standard formats.

Also the Wuffs documentation is a bit hard to understand. It's a litle bit of a mission getting PNG decoding working. You can see my code for that here though: https://github.com/glaretechnologies/glare-core/blob/2c7174c...

Re: Wuffs: Wrangling Untrusted File Formats Safely

#26

Post by csande17 »

jszymborski wrote: post #23
timschmidt wrote: post #15

Earlier quoted context omitted.

I wrote an SVG that's all javascript, no elements. All the graphics are generated dynamically at runtime by the javascript. It's SVG standards compliant, but only opens correctly in browsers, not in inkscape or other desktop publishing apps. I work a lot in OpenSCAD, and had a need to design some custom graph paper. So I found the subset of SVG which was similar to OpenSCAD. :)

Frankly, I wouldn't begrudge a website for not correctly parsing an svg I composed entirely with javascript. It's annoying you can't just "flatten" or "bake" such an svg like yours into one composed entirely of elements (unless one exists?)

Often you can open the SVG in a browser and then use the developer tools to copy out the resulting nodes as "flat" SVG source code.

Chrome even includes a --dump-dom flag you can use to do this on the command line, although I haven't tested it with an SVG.

Re: Wuffs: Wrangling Untrusted File Formats Safely

#27

Post by tomjakubowski »

vlovich123 wrote: post #16
tialaramex wrote: post #10

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…

I’m responding to this: > that can then be shipped like normal C, so you don't get the ecosystem friction like with ex. Rust. Emitting Rust doesn’t help with this.

it helps in the other direction: less friction to use from rust

Re: Wuffs: Wrangling Untrusted File Formats Safely

#28

Post by jay-barronville »

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

Re: Wuffs: Wrangling Untrusted File Formats Safely

#29

Post by refibrillator »

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.

Re: Wuffs: Wrangling Untrusted File Formats Safely

#30

Post by repsilat »

Ono-Sendai wrote: post #24

Wuffs is great. I use it in Substrata ( https://substrata.info/ ) for loading PNGs. It is both faster and safer than LibPNG. It's something around 2x faster than LibPNG in my tests (depending on the PNG file), see timings here: https://github.com/google/wuffs/issues/13#issuecomment-17325... So generally Wuffs is great and you should use it to decode your PNGs. There are some downsides: not all of the obscure bit dept…

The "mango" lib [1] claims to be even faster for PNGs. Actively maintained but doesn't have as much buzz, I think the devs haven't advertised it as much on places like this.

Also, it has the funniest testimonials.

1: https://github.com/t0rakka/mango

Post reply on HN