HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
google
wuffs
C2017–2026
google / wuffs

wuffs

Wrangling Untrusted File Formats Safely

Security & PrivacyLanguages & CompilersCreative & Media
Explore on GitHubRead Hacker News discussions
76Distinct people
121Mentions
0Explicit recommenders
4.9KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Wrangling Untrusted File Formats Safely

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 6:01:32 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year121 dated mentions

Observed mentions: 2017-11-16 05:54:56 UTC to 2026-10-29 00:33:25 UTC.

01020302017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 11 mentions; 4 submissions, 7 comments20172018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 2 mentions; 2 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 6 mentions; 2 submissions, 4 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 28 mentions; 5 submissions, 23 comments20212022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 20 mentions; 0 submissions, 20 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 16 mentions; 2 submissions, 14 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 14 mentions; 2 submissions, 12 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 12 mentions; 0 submissions, 12 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 11 mentions; 0 submissions, 11 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC1147
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC110
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC220
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC624
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC28523
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC20020
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC16214
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC14212
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC12012
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC11011

What Hacker News says

28 sources
awinter-py·Dec 23, 2021
agree -- ultra useful alternative to splitting would be neat to imagine a language where this was an optimizer feature rather than a decision the programmer made. many functions that return an array are ultimately using just one, or a few elements of it. the compiler can make a lot of decisions in the caller about how to reduce allocation or short-circuit array processing. I think, but am not sure, this is what the experimental parsing language 'wuffs' is about https://github.com/google/wuffs -- the language itself is aware of array lengths as a first-class citizen and can make decisions accordingly
In Three Minor Features in Go 1.18
tialaramex·Jul 16, 2021
For a codec, WUFFS might be a better fit than Rust. https://github.com/google/wuffs In Rust, if I have two u8 variables and I add them together, Rust will try to figure out if it's sure at compile time that this is an overflow and if so reject it, but otherwise I get a binary which might have an overflow in it. But in WUFFS when you add those variables together, WUFFS wants you to justify why that can't overflow, or, tell it that you know it does overflow and you want wrapping or whatever. As a result, WUFFS gets to be very confident the resulting (awful, machine generated) C is safe and correct. As you observed, this sort of confidence also permits a lot of performance tricks. WUFFS has some very impressive (ie better than existing Rust code) benchmark scores for the (much simpler) codecs like JPEG or PNG but I don't think there's any re
Read the rest
ason it couldn't shoot for MPEG or beyond. WUFFS is no rival to Rust. It doesn't have IO for example. Which is fine, your codec implementation shouldn't do IO. WUFFS deals in blobs of bytes. Bytes you got over the network or from a file go in, and bytes represented a decoded image, decompressed file, or whatever come out.
In Is Rust Used Safely by Software Developers?
tialaramex·Jun 27, 2021
I don't agree. Consider WUFFS https://github.com/google/wuffs WUFFS will give you a C library that can turn PNG data into raw image data and is definitely correct. It's not exactly idiomatic C, you'd assume if a person wrote this code it's probably wrong, but WUFFS promises it's correct. CompCert should turn that C library into executable code which is therefore also definitely correct. Now, maybe you will screw up code that reads the PNG data from a disk file, or draws the image on a screen, or a million other things, but the WUFFS library components are definitely fine, not just "Bill wrote it and he's got 20 years experience" fine or "It passed the unit tests" fine but "Four Color Theorem" fine.
In CompCert – Formally-verified C compiler
tialaramex·Jun 7, 2021
The way you get bitten is that there's an opportunity to trade off security versus functionality. Imagine you've got the alleged bomber's computer, it has hundreds of thousands of images with long hexadecimal names like 384d38b0c32aaf03.jpg and you're under pressure to figure out where the missing fifth bomb is before everybody finds out the hard way. Now, on one hand you've got a simple image viewer built with WUFFS: https://github.com/google/wuffs which you are completely sure is safe for viewing the images, you could perhaps glance at a hundred images per hour, although if there's anything subtle you'd miss it. On the other hand, you've got a fancy AI-assisted tool that processes over 1000 images per minute and cross-matches them with over a hundred law enforcement databases and other sources to understand what it sees. It might be abl
Read the rest
e to pick out anomalous images in time to make a difference. Still, it was written in C++ and the last time you used it the program crashed three times with mysterious errors. Which do you choose? If the bomb blows up and kills sixty elementary school kids while you're glancing at image #406 having not noticed that school is in the background of images #284, #301, #305, #313, and #326 and never guessing that the unknown interiors in images #192-198 and #350-400 are from that same school - you're going to feel like an idiot for choosing the slow path. But if the bomb blows up when your AI assisted image processor is exploited by a C++ JPEG library zero day inside image #4861 and that sends the "explode now" code to a custom web site the bomber set up for exactly this eventuality, you're going to feel like an idiot for not using WUFFS. This sort of trade-off is how Vinge's "A Fire Upon the Deep" begins. Humans (roughly) are poking around in an apparently forgotten archive in deep space. They could be slow and careful, but it's too tempting to choose quicker methods, smarter methods, letting the archive direct how to improve their AI to better understand it. By the time the humans realise their AI is doing what the archive wanted it to do, not what they wanted it to do, it's far too late for them.
In Gene sequencer malware injection via encoded DNA (2017)
tialaramex·May 14, 2021
Alas, the nature of computation makes this only ever a matter of squinting hard enough at the problem. Just as it turns out that matter and energy are almost the same thing seen from a different point of view, it's the same with code and data. Running code and processing data are no different to a computer. You think a picture of a dog and a Windows program are plainly different kinds of things, the computer does not agree. Something like Wuffs † aims to at least control the blast radius. If (in some alternate or far future world) you were only ever looking at pictures of a dog via Wuffs, you could at least feel confident that doing so did not have some entirely unforeseen consequences, like exfiltrating your SSH private keys. Today you certainly can't be sure of that, none of the tools you use have such a cautious approach. † https://git
Read the rest
hub.com/google/wuffs
In Using Rust Macros to exfiltrate secrets
chubot·Apr 8, 2021
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 a few dimensions. --- 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... The canonical example of this class of bug is forging SSL certificat
Read the rest
es to take advantage of buggy parsers, but I don't have a link handy. There should be one off of https://langsec.org/ if anyone can help dig it up. 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. It's short, but it really needs a better regex metalanguage to be readable: https://www.oilshell.org/release/latest/doc/eggex.html A large part of JSON can be described by regular languages, and same with HTTP, etc. ----- edit: An re2c target for wuffs could make sense. The generated code already doesn't allocate any memory, although it uses tons of pointers which could be dangling. And in fact that was a problem Cloudflare, which sprayed the user data of their customers all over the Internet back in 2017: https://en.wikipedia.org/wiki/Cloudbleed That was with Ragel and not re2c, which perhaps has a more error prone API.
In Wuffs the Language
nigeltao·Apr 8, 2021
> I'm curious if it is at all competitive with the Wuffs decoder You could try adapting https://github.com/google/wuffs/tree/main/script/bench-rust-... > https://github.com/bschwind/png-decoder Note that statements like: let bytes_per_scanline = ((header.width * header.bit_depth as u32 * header.color_type.sample_multiplier()) + 7) / 8; can silently overflow a u32 if width is 0x800_0000, bit_depth is 8 and sample_multiplier is 4. Part of the point of Wuffs is to catch things like that (at compile time).
In Wuffs’ PNG image decoder

Showing the 15 most recent of 28 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.