search

freedomofpress / dangerzone

Take potentially dangerous PDFs, office documents, or images and convert them to safe PDFs
https://dangerzone.rocks/
GNU Affero General Public License v3.0
3.74k stars 172 forks source link

Small fixes for issues we encountered during the 0.8.0 release #996

Closed apyrgio closed 1 day ago

apyrgio commented 1 week ago

This PR tackles the following minor issues:

  1. Make the dz qube larger, now that we ask users to download Tesseract data. Initially the /home disk size was 2GiB, and with this change, we bump it to 5GiB.
  2. Remove a reference to a second container from our README.
  3. Update our QA script to implement two more steps from our instructions.
apyrgio commented 1 week ago

@deeplow: One quick question about https://github.com/freedomofpress/dangerzone/pull/996/commits/8f8252eff810ef4723005d872a4664aab8f8d281. I haven't found a way to create an app qube and define the disk size at the same time, hence the separate command. Do you know of a more canonical method?

deeplow commented 1 week ago

As far as I'm aware qube creation is solely done by the qvm-create and qvm-clone commands and they don't allow for control of volume creation other than where it will be created. So it has to be a separate command. Also, I don't think it being exactly 5GiB is strictly necessary, but it does not harm (other than a longer commmand).

deeplow commented 1 week ago

An additional potential improvement (which I haven't checked if it exist or not) would be to check if there is enought space available before downloading tesseract data. This could be helpful also on non-Qubes systems.

It will be really nice when this turns into a multiVM application (kind of like SecureDrop) where updates also happen at the Qubes-level, so that the user doesn't have to keep reconfiguring the system. But that's a longer effort, especially because the installation and update story is not very polished yet.

update: never mind. I thought I was looking at the INSTALL instructions and not the BUILD (a.k.a. dev-facing ones). There's of course no need to build guard-rails for those. But this reminded me that there may be challenges getting dynamically downloaded OCR languages (https://github.com/freedomofpress/dangerzone/issues/488) to work on Qubes. I'll write on the respective ticket (DONE).