Papers: Proof of Concept for backend isolation

Project title

Mentors

Myself (@pabloyoyoista), with help from the other maintainers, Qiu (@crab2313) and Markus (@camelCaseNick)

We might also get some sporadic help from @mcatanzaro

Project length

"Long ~350 hours"

Description

This project will mostly require work on Papers' libraries: ppsview and ppsdocument. The former contains an abstraction (PpsJob) to run (potentially slow) backend code in threads. The later is basically a common abstraction over different backends: PDF, DJVU, Tiff, etc. The idea is to create a component that will start a new process per-document (similar to web-browsers having one process per tab!). That side-car process will take care of all the calls to the backends (so embedded in ppsdocument), and be managed by PpsJobs. Further details are available in GNOME/Incubator/papers#104

The idea for the GSoC will be for the Intern to prototype a solution to this problem, and investigate potential solutions and foot-guns. The intern will need quite a good knowledge on C, and have motivation to do some investigate work (e.g: look into solutions implemented by other projects like WebKit). I don't expect a full implementation or solution, even if that would be welcomed. A failed attempt at this might already gives us extremely valuable input.

This will benefit Papers as the future Document Viewer in GNOME in two ways:

By isolating documents from each other, we improve the overall security situation. Even CVEs that might allow somebody to gain access to execution code from rendering a PDF would not have access to the other documents.
By isolating documents from the UI we improve the resilience of Papers. A document crashing during rendering (for which CVEs happen regularly (last one CVE-2024-6239) will not bring down with itself the complete application. This has been so far the main blocker to implement the Document Viewer tabbed view, which has been a feature request for Evince since 2005

Requirements

Good skill and experience in the C programming language. Both be able to write and read it
The ability to investigate previous approaches to solve the same issue. We will guide the Intern on where to look
Motivation to try different approaches. We know a big part of this project will be checking the feasibility of different solutions

Communication

Our preferred communication channel is Matrix (https://matrix.to/#/#papers:gnome.org), but we will also do video-calls to get onboarded and if deemed useful and necessary for the mentoring process