Generalize trusted file conversion beyond PDFs

[Jayant-kernel]

Summary

This tracks the GSoC work to generalize the Qubes PDF converter into a safer file conversion flow for more untrusted formats.

The existing qvm-convert-pdf design is the base: parsing and rendering happen inside a Disposable VM, and the client receives only simple output data to rebuild a trusted file. The goal is to keep that model, keep qvm-convert-pdf backward compatible, and add a generic qvm-convert-file path for other formats.

Planned direction

• Keep qvm-convert-pdf and qubes.PdfConvert working as they do today.
• Add qvm-convert-file with MIME-based dispatch instead of trusting file extensions.
• Start with PDF-only dispatch, then add document conversion in small steps.
• For office-like files, convert to PDF inside the Disposable VM, then reuse the existing PDF-to-pixels style pipeline.
• Learn from Dangerzone's document conversion design where it makes sense, while keeping the Qubes implementation compatible with qrexec and Disposable VMs.
• Decide later how the generic command should interact with the existing Qubes image converter, rather than duplicating that work.

First steps

1. Split PDF rendering from the common server flow.
2. Add a small renderer dispatch/interface, with PDF as the first renderer.
3. Add qvm-convert-file with PDF-only MIME dispatch.
4. Add client-side service/profile routing for future converters.
5. Add the first document renderer and qrexec service after the structure is reviewed.
6. Add tests, hardening, docs, and desktop integration as the supported formats grow.

Non-goals for the early PRs

• No change to the existing PDF wire protocol unless explicitly reviewed.
• No large "all file types at once" PR.
• No direct import of the full Dangerzone app.
• No GUI/OCR/media work before the core document path is reviewed.

Related PRs

• pdf-converter: split server PDF rendering qubes-app-linux-pdf-converter#42
• pdf-converter: add renderer dispatch qubes-app-linux-pdf-converter#43
• pdf-converter: add qvm-convert-file PDF dispatch qubes-app-linux-pdf-converter#44

Done when

• qvm-convert-pdf remains backward compatible.
• qvm-convert-file exists and dispatches supported formats by MIME type.
• At least one non-PDF document path works through a Disposable VM.
• Failure cases and unsupported types are handled clearly.
• Tests and docs cover the supported formats and safety tradeoffs.

[apyrgio]

Some useful DZ context, in case it helps:

• The server-side component of Dangerzone (i.e., "doc to pixels")
  • The Qubes policies and build scripts.
• The client-side component of Dangerzone (i.e., "pixels to doc"), which is sandbox-agnostic. This means that it's generic enough to work with containers or qubes.
  • Case in point, this is our tiny Qubes-only logic.
  • We have a dev-only hack that teleports Python zipfiles to the disposable qube, in order to not constantly edit disp vm templates all the time. I'm pointing it out because it made our lives easier during testing.
• And finally, the list of open issues to stabilize our Qubes integration.

Oh, and one small note:

Add qvm-convert-file with MIME-based dispatch instead of trusting file extensions.

We've taken care not to check the MIME type on the client-side, or parse any part of the file, in general. So far, we haven't encountered any issues while doing it on the server-side.

[marmarek]

We've taken care not to check the MIME type on the client-side, or parse any part of the file, in general. So far, we haven't encountered any issues while doing it on the server-side.

How do you handle a case where output format would depend on the input one? For example video or audio file?

@Jayant-kernel but generally, it's a good idea to do as little processing on the client side. See for example server side here: https://github.com/freedomofpress/dangerzone-image/blob/main/src/dangerzone_insecure_converter/doc_to_pixels.py

[apyrgio]

How do you handle a case where output format would depend on the input one? For example video or audio file?

For docs/images, this hasn't been the case yet.

For audio/video, this is indeed the case. The PoC we recently had was revolved around containers, and in that case, we:

• issue an "index" command first to the server, that among other things extracts archives and reports back the names of the files and their type (enum)
• issue a separate "convert" command per file, tailored to the type of the file that the client received from the "index" command.

My best bet on how this would translate on Qubes would be with a preloaded disposable, for performance reasons, but I don't have any code on that, I'm afraid.

If you decidedly don't want to deal with attachments, another alternative I had in mind is:

1. (client) Guess the proper sanitizer type based on the extension (usually the choice will be correct).
2. (server) Verify whether a sanitizer can apply to a file type, based on its MIME type. If not, exit with a predefined error code.
3. (client) If the error is a MIME type mismatch, retry the operation with the correct sanitizer.

[Jayant-kernel]

Okay
I have moved the MIME/type dispatch to the server side , so the client no longer checks the untrusted file type.

[Jayant-kernel]

Progress note - May 29, 2026

• Updated PR New template and net vm for Alpha 2 #44 after the feedback about avoiding client-side file checks.
• The file type handling is now done on the server/DisposableVM side.
• The first qvm-convert-file version still supports only PDFs.
• Next step is to get this structure reviewed before adding document formats.