Related, in the sense of solving the same problem in a different manner: https://rlbox.dev/
Wuffs: Wrangling Untrusted File Formats Safely
11–20 of 73 posts
Re: Wuffs: Wrangling Untrusted File Formats Safely
#12Does 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…
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 ?
Re: Wuffs: Wrangling Untrusted File Formats Safely
#13Does anyone know of a tool that can do this for PDFs instead?
[deleted]
Re: Wuffs: Wrangling Untrusted File Formats Safely
#14Earlier quoted context omitted.
It’s an interesting idea for sure but it isn’t a general purpose language, so the problem domains it can solve is very very different vs what Rust is trying to do.
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?
Re: Wuffs: Wrangling Untrusted File Formats Safely
#15Earlier quoted context omitted.
As soon as someone writes a Javascript interpreter in Wuffs..
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. :)
Re: Wuffs: Wrangling Untrusted File Formats Safely
#16Earlier quoted context omitted.
It’s an interesting idea for sure but it isn’t a general purpose language, so the problem domains it can solve is very very different vs what Rust is trying to do.
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.
Re: Wuffs: Wrangling Untrusted File Formats Safely
#17Earlier 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?
Nominally it can safely elide bounds checks via unsafe that it has proved are actually safe within the constraints of Wuffs, which is what it does for C (+ the language is built for more easy translation to vectorizated than something like llvm is able to do for general purpose languages).
So basically higher performance.
FFI nominally has a runtime and compile time cost - whether that matters for you in particular will depend on your needs, but being able to publish a very simple crate without a build.rs to manage can have an attraction.
Re: Wuffs: Wrangling Untrusted File Formats Safely
#18Earlier 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…
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 sustainably mitigate the complex leaky dependency mess on traditional architectures. It has been my experience that "all software is terrible, but some of it is useful".
It may just be my bias, but I see code smell getting worse in recent decades...
Have a nice day, =3
Re: Wuffs: Wrangling Untrusted File Formats Safely
#19Does anyone know of a tool that can do this for PDFs instead?
Re: Wuffs: Wrangling Untrusted File Formats Safely
#20Earlier 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?
I expect that the Rust emitted by a hypothetical future WUFFS transpiler would be much easier to just drop into an existing Rust project than some C via a C FFI.
It's common for C libraries that do get wrapped today (e.g. openssl) to have a two phase wrapping, a -sys crate which turns the C into Rust C FFI and then another crate to turn the Rust C FFI into something actually palatable to ordinary people.