This looks better than q(ubes)-pdf, but still not ideal.

Seems that PyMuPDF is used with a fixed (single pathname) "/tmp/input_file" ? https://github.com/freedomofpress/dangerzone/blob/main/dange...

Everything else is tossed through LibreOffice.

Meanwhile what I'd prefer for PDFs is some allow-listed set of 'safe' PDF operations (layout image, layout text) to be used with sanitized inputs (no underflows, overflows, corruption, etc), and the results of any at snapshot-runtime code evaluated and then flattened out to a safe element. Image OCR could be run atop that.

Similarly it'd be nice if a filter like that existed for the other documents, but as an individual contributor I don't have the human power to keep up with that goal and would take the same low hanging fruit worse but secure output route.

> allow-listed set of 'safe' PDF operations (layout image

That's the problem right there. PDF supports many image formats, including ones that are useful but you may have never heard of like JBIG2 for scanned documents. And the parser for those image formats needed to be secure as well. One very famous exploit is just exploiting JBIG2 (among other things): https://googleprojectzero.blogspot.com/2021/12/a-deep-dive-i...

You could simply not support those obscure image formats?

And when a journalist receives a tip from a reliable source they can't open with their secure PDF tool, they are more likely to do what? Disregard the info, or open the PDF in an unsafe tool?

That's not an option. JBIG2 is objectively the best format for compressing black-and-white scanned images. The Adobe Acrobat software has an "optimize scanned PDF" feature that produces this format. It's not obscure at all.

That objectively best format that was banned in some areas due to replacing important numbers in accounting documents? But if it's the default in Acrobat, yeah, likely not obscure enough

In terms of threat model, what is the problem with MuPDF in gVisor (a very tight sandbox)? Obviously, a memory-safe language would be ideal, but there's nothing fundamentally wrong with the approach.

Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern.

A single fixed path for the temporary input file means only one copy of the converter can run at a time (unless it's in a sandbox, which wasn't clear from the context). A PID specific tempfile or, better, use a standard 'make a new temp file name so there's not a collision' utility, would allow parallel conversions.

Hey, Dangerzone dev here. Just wanted to say that the temporary input file is actually within a sandbox - and there's one sandbox per file - so there's no collision with other files in the host.

> Someone could potentially use the underlying tools directly in their own needs workflow, or an expert in those tools could mention if there's a vulnerability / common mistake pattern.

Yep, that's something we cover in our about page. We process the untrusted document in a gVisor sandbox, that runs within a hardened Linux container, that runs within a Docker Desktop VM (in Windows/macOS). And yet, that doesn't mean that Dangerzone can't get hacked by a determined (possibly state-backed) attacker. So yeah, you have a point.

At the same time, using tools like this raises the "you must be THIS determined to enter" bar. This means attackers must spend much more money, time, expertise, 0-days, etc. These resources are finite, so more people are protected as a net result, even if we can't protect everyone. That's the way I see it at least.

very good answer :)

I appreciate this! It would add another attack vector, but I could see the utility in SaaS'ifying this for servers to convert user-uploaded content on-the-fly.