Qubes: RPM Packaging

[deeplow]

Package Dangerzone for Qubes OS in a way that satisfies the following requirements:

• ✔️ Do not include the container image, as is the case for the rest of our packages.
• ✔️ Use the Qubes OS isolation provider (Add Qubes OS isolation provider #414).
• ✔️ Contain the dependencies necessary to run both the client and the dispVM parts of the conversion.
• ✔️ Target the default Qubes OS template (Fedora 38 as of writing this).
• ✔️ Avoid installing dangerzone-signed code in dom0
• ⚠️ Install the necessary Tesseract OCR data (see Qubes: Install all other OCR languages #438 (comment))
• ⏳ : Include it in our freedomofpress/yum-tools-prod repo.

Related discussions:

• What’s the Future Of Multi-VM Applications? (Qubes Forum)

[eloquence]

What we discussed today as goals for the 0.5.0 release:

• We'll ship dedicated RPM and, as a stretch goal, DEB packages for Qubes via packages.freedom.press. These will be much smaller than our standard packages since we do not need to ship a container image.
• Installation will require manual steps, likely including:
  • configuration of the packages.freedom.press repository in the desired template
  • creation of a networkless disposable VM template
  • configuration of RPC policies

For now, we're not focusing on providing a dom0 installer or script, but we'll discuss more with both the Qubes team & the SecureDrop team how we want to approach provisioning in the long run.

Please let me know if that's an accurate summary or if I'm missing anything!

[deeplow]

Please let me know if that's an accurate summary or if I'm missing anything!

I think it is :)

[apyrgio]

Install the necessary Tesseract OCR data

I have tested adding Requires: tesseract-langpack-* in the RPM spec for Dangerzone, but it turns out that, while the package can be created, installation fails with:

Error: 
 Problem: conflicting requests
  - nothing provides tesseract-langpack-* needed by dangerzone-qubes-0.4.2-1.fc38.x86_64 from @commandline

Unfortunately, Fedora does not offer the equivalent virtual package of tesseract-ocr-all in Debian, so we're left with three options:

1. Enumerate all the tesseract language packages (123 as of writing this) within the RPM spec file.

   • We may be able to script this by taking advantage of our ocr-languages.json file, but I haven't tested it yet.

2. Ask the user in our installation instructions to install dangerzone-qubes tesseract-langpack-*, allowing them to substitute tesseract-langpack-* with any language pack that they plan to use.

3. Make the Tesseract language models for the first 10 most spoken languages in the world a direct dependency. These languages are:

   • English
   • Chinese (Mandarin)
   • Hindi
   • Spanish
   • French
   • Arabic (Standard)
   • Bengali
   • Portuguese
   • Russian
   • Urdu

   (Source: https://www.statista.com/statistics/266808/the-most-spoken-languages-worldwide/)

   They are spoken by ~5.37 billion people (66.7% of the total world population). For reference this is where Qubes users were located in 2020:

   

   (Source: https://www.qubes-os.org/news/2020/11/26/qubes-survey-results/)

   We can have a note in our installation instructions, for Qubes users that are not covered by these languages, that they can install them in their fedora-38-dz template directly with dnf install -y tesseract-langpack-<lang>.

I'm leaning towards (3), because that's where we want to ultimately go with Dangerzone (#465, #448, #488). What do other people think?

---

Edit: @eloquence and @deeplow prefer option (1), so we will go with that.

[apyrgio]

Installation instructions

Since template VMs don't have network attached, it would have been tricky installing Dangerzone, since we need to download keys, configuration, and the actual packages.

Thankfully, our existing commands:

sudo dnf config-manager --add-repo=https://packages.freedom.press/yum-tools-prod/dangerzone/dangerzone.repo
sudo dnf install dangerzone

all pass through the updates proxy.

[eloquence]

Enumerate all the tesseract language packages (123 as of writing this) within the RPM spec file.

As discussed in team meeting, that would be my vote for now. We'll want to a more robust approach to languages across platforms, with a lean default configuration and optional downloading ideally triggered via the UI. But I'd prefer to avoid doing something bespoke just for Qubes right now, also in terms of "principle of least surprise".