wuffs

Wrangling Untrusted File Formats Safely (by google)

Stats

Basic wuffs repo stats
22
2,728
9.6
4 days ago

google/wuffs is an open source project licensed under Apache License 2.0 which is an OSI approved license.

Wuffs Alternatives

Similar projects and alternatives to wuffs

  • GitHub repo smhasher

    Hash function quality and speed tests

  • GitHub repo png-decoder

    A pure-Rust, no_std compatible PNG decoder

  • GitHub repo rust

    Empowering everyone to build reliable and efficient software.

  • GitHub repo stb

    stb single-file public domain libraries for C/C++

  • GitHub repo Halide

    a language for fast, portable data-parallel computation

  • GitHub repo haxe

    Haxe - The Cross-Platform Toolkit

  • GitHub repo MSRC-Security-Research

    Security Research from the Microsoft Security Response Center (MSRC)

  • GitHub repo dhall

    Maintainable configuration files

  • GitHub repo security-research

    This project hosts security advisories and their accompanying proof-of-concepts related to research conducted at Google which impact non-Google owned code.

  • GitHub repo ivory

    The Ivory EDSL

  • GitHub repo Compiler

  • GitHub repo image-png

    PNG decoding and encoding library in pure Rust

  • GitHub repo ableC

    Attribute grammar Based Language Extensions for C

  • GitHub repo mango

  • GitHub repo mango

    mango fun framework (by atkurtul)

NOTE: The number of mentions on this list indicates mentions on common posts. Hence, a higher number means a better wuffs alternative or higher similarity.

Posts

Posts where wuffs has been mentioned. We have used some of these posts to build our list of alternatives and similar projects - the last one was on 2021-04-07.
  • Wuffs (Programming Language) – Wrangling Untrusted File Formats Safely
    news.ycombinator.com | 2021-04-09
  • Wuffs the Language
    news.ycombinator.com | 2021-04-07
    Wuffs seems fascinating and I really wanted to like it. But when I look at the code for the JSON decoder it seems so low level, and full of places for bugs to hide. JSON is a pretty simple spec and this obscures it (although to be fair it's also handling UTF-8).

    https://github.com/google/wuffs/blob/main/std/json/decode_js...

    Yes it prevents buffer overflows and integer overflow, but it can't prevent logical errors.

    I'd rather see efficient code generated from a short high level spec, not an overwhelming amount of detail in a language verified along one dimension.

    Logical errors in parsing also lead to security vulnerabilities. For example, here is an example of parser differentials in HTTP parsing:

    https://about.gitlab.com/blog/2020/03/30/how-to-exploit-pars...

    I think the canonical example is forging SSL certificates to take advantage of buggy parsers, but I don't have a link handy. Again, this has nothing to do with buffer or integer overflows.

    (aside: while googling for that I found the claim that mRNA vaccines work by parser differentials: https://twitter.com/maradydd/status/1342891437537505280?lang... If anyone understands that I'd be curious on an opinion/analysis :) )

    At the very least, any language for parsing should include support for regular languages (regexes). The RFCs for many network protocols use this metalanguage, and there's no reason it shouldn't be executable. They compile easily to efficient code.

    The VPRI project claimed to generate a TCP/IP implementation from 200 lines of code, although it's not really a fair comparison because it hasn't been tested in the wild: https://news.ycombinator.com/item?id=846028 .

    Still I think that style has better engineering properties. Oil's lexer, which understands essentially all of bash, is generated from a short source file

    https://www.oilshell.org/release/0.8.8/source-code.wwz/front...

    which generates

    https://www.oilshell.org/release/0.8.8/source-code.wwz/_devb...

    (which goes on to generate 28,000 lines of C code)

    news.ycombinator.com | 2021-04-07
  • BleedingTooth: Linux Bluetooth Zero-Click Remote Code Execution
    news.ycombinator.com | 2021-04-07
    Web development is done mostly using "memory safe" languages and we can see that it is far from being secure. The list looks like: https://owasp.org/www-project-top-ten/

    Which is not to say that "memory safety" is not a significant issue in C/C++. I wonder why wuffs [1] is rarely used in C projects to parse untrusted data given that it can be translated to C.

    [1] https://github.com/google/wuffs

  • Wuffs (Wrangling Untrusted File Formats Safely)
    news.ycombinator.com | 2021-04-07
  • The Fastest, Safest PNG Decoder in the World
    Generating Go and Rust code is listed as a long term goal at https://github.com/google/wuffs/blob/main/doc/roadmap.md
    https://github.com/google/wuffs/blob/main/doc/related-work.md#why-not-ats
    Sorry, I forgot to mention that. The fuzzers are at https://github.com/google/wuffs/tree/main/fuzz/c/std
    The language has ways of defining type refinements and identifying facts to ensure that arithmetic can't cause an overflow, and it will cause a compiler error if you specify any arithmetic that can't be proven not to overflow. (See bounds checking.)
    The readme has a straightforward example, where adding a + 1 causes a compiler error.
  • Wuffs PNG decoder faster than rust
    reddit.com/r/rust | 2021-04-06
    I created a PR here: https://github.com/google/wuffs/pull/45
    reddit.com/r/rust | 2021-04-06
    I was looking at the Rust benchmark's decode function and the color encoding conversion caught my eye. I was curious if I could force the compiler to remove the bounds checks on each access... but no luck!