[HN Gopher] Wuffs: Wrangling Untrusted File Formats Safely
       ___________________________________________________________________
        
       Wuffs: Wrangling Untrusted File Formats Safely
        
       Author : nequo
       Score  : 67 points
       Date   : 2024-05-16 13:48 UTC (1 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | dang wrote:
       | Related:
       | 
       |  _Wuffs the Language_ -
       | https://news.ycombinator.com/item?id=26731305 - April 2021 (75
       | comments)
       | 
       |  _Wuffs' PNG image decoder_ -
       | https://news.ycombinator.com/item?id=26714831 - April 2021 (138
       | comments)
        
       | newman314 wrote:
       | Does anyone know of a tool that can do this for PDFs instead?
        
         | warkdarrior wrote:
         | As soon as someone writes a Javascript interpreter in Wuffs..
        
           | jchw wrote:
           | 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.)
        
         | Joel_Mckay wrote:
         | 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 VM to transcode a "web" version, and scrub
         | each stage of the rendering pipeline like a virus or header
         | injection is already present.
         | 
         | "I never play where nice things are, and don't break things"
         | (Eliza Mowry Blven, The Humanitarian Review, Volume 3, March,
         | 1905)
         | 
         | Cheers =3
        
           | tialaramex wrote:
           | 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 ?
        
       | yjftsjthsd-h wrote:
       | This is one of my favorite attempts at better programming
       | language safety, because it compiles down to C that can then be
       | shipped like normal C, so you don't get the ecosystem friction
       | like with ex. Rust.
        
         | vlovich123 wrote:
         | 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.
        
           | tialaramex wrote:
           | 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 serious typo]
        
       | tedunangst wrote:
       | Related, in the sense of solving the same problem in a different
       | manner: https://rlbox.dev/
        
       ___________________________________________________________________
       (page generated 2024-05-17 23:00 UTC)