* Package name    : dangerzone
  Version         : 0.1.5
  Upstream Author : Micah Lee
* URL             : https://dangerzone.rocks/
* License         : MIT/X or expat?
  Programming Lang: Python
  Description     : Take potentially dangerous PDFs, office documents, or images and convert them to a safe PDF

Dangerzone works like this: You give it a document that you don't know
if you can trust (for example, an email attachment). Inside of a
sandbox, Dangerzone converts the document to a PDF (if it isn't
already one), and then converts the PDF into raw pixel data: a huge
list of of RGB color values for each page. Then, in a separate
sandbox, Dangerzone takes this pixel data and converts it back into a
PDF.

 * Sandboxes don't have network access, so if a malicious document can compromise one, it can't phone home
 * Dangerzone can optionally OCR the safe PDFs it creates, so it will have a text layer again
 * Dangerzone compresses the safe PDF to reduce file size
 * After converting, Dangerzone lets you open the safe PDF in the PDF viewer of your choice, which allows you to open PDFs and office docs in Dangerzone by default so you never accidentally open a dangerous document

Dangerzone can convert these types of document into safe PDFs:

 * PDF (.pdf)
 * Microsoft Word (.docx, .doc)
 * Microsoft Excel (.xlsx, .xls)
 * Microsoft PowerPoint (.pptx, .ppt)
 * ODF Text (.odt)
 * ODF Spreadsheet (.ods)
 * ODF Presentation (.odp)
 * ODF Graphics (.odg)
 * Jpeg (.jpg, .jpeg)
 * GIF (.gif)
 * PNG (.png)
 * TIFF (.tif, .tiff)

Dangerzone was inspired by Qubes trusted PDF, but it works in
non-Qubes operating systems. It uses containers as sandboxes instead
of virtual machines (using Docker for macOS, Windows, and
Debian/Ubuntu, and podman for Fedora).

===

The build instructions seem to say there aren't that many deps, and
possibly that all of them are in Debian already:

https://github.com/firstlookmedia/dangerzone/blob/master/BUILD.md

It seems like it also requires Docker, which we now have in Debian,
but that might be a problem for shipping with stable in the long term.

A better approach for upstream might be to use podman, or manage
containers itself, with bubblewrap or firejail or equivalent.

Those tools, obviously, are alternatives that might be a good fit as
well, but since they are much more bare bones, i think it would still
be nice to have dangerzone in Debian.

I'd be happy to comaintain this in Debian with the Python team.

Hello Antoine,

I'd like to package this application.
Before finding your RFP I thought of proposing to maintain it under umbrella of
the privacy pkg team, but that also makes sense. Could also imagine
(co)maintaining it.

I have done some initial packaging[1], but I think it should definitely ship
with an autopkgtest at least for the cli binaries that are included. Hope I can
look into that next month, but since testing is frozen anyway I think there is
no hurry

kind regards,
Peymaneh

[1] https://salsa.debian.org/peymaneh/dangerzone

Hi Peymaneh,

I'm wondering if you have any update on packaging or anything I can help
with. I would like to sunset src:pdf-redact-tools (now archived
upstream) in favor of dangerzone.

Thanks!
-- Kunal

Hi Kunal,

Am 25.02.22 um 07:30 schrieb Kunal Mehta:

I was done packaging v0.2.1, unfortunately upstream came up with a new
release 😅
I will need to adjust the build scripts in order for v0.3.1 to build,
I'll look into that next week

kind regards
Peymaneh

Hi,

excuse the long silence!
I have packaged the latest version and I believe it is in a good state.

@Kunal
Would you mind having a look at it? This is my first package including
post{inst,rm}-scripts and I am not sure if the way i did it is very robust.

I have uploaded the package on salsa[1] and am also asking for feedback
on the mentors list.

For context:
For the new version upstream has decided to include build a whole
Container-Image at build time and include the 700MB image in the .deb
package. The absurd package size set aside, building the image on the
Debian build servers would not be possible because a network connection
is required for pulling the docker image.
My dangerzone.postinst is basically the build-script from upstream[2]
only with some very basic error-handling added to it.

Kind regards,
Peymaneh


[1] https://salsa.debian.org/peymaneh/dangerzone
[2]
https://salsa.debian.org/peymaneh/dangerzone/-/blob/53d3e5b75e7d97fb77f09e45db57195a8aa4ed7d/install/linux/build-image.sh

Hi,

Yay! Comments unrelated to the postinst:

* I think dangerzone-container.1 might be outdated, it references
`docker` instead of `podman`.
* in d/rules, just remove the `export DH_VERBOSE` line entirely and use
the default.
* Is python3-stdeb needed? I might've missed something.
* You can drop d/source/local-options, everything is commented out.
* Please try to upstream the .desktop patch

Definitely agreed that shipping the container in the package itself
would be a big mistake and not feasible for multiple reasons.

I think what you have now is probably acceptable for contrib[1], but far
from ideal, both practically and for the goal of getting it into main.
My opinion of ideal behavior would be that the first time Dangerzone is
opened, it notices the lack of the image, and then starts building it or
pulling it from somewhere (with or without a prompt). It would be worth
discussing such a behavior change with upstream first though. An Arch
Linux maintainer has already asked for something similar at
<https://github.com/firstlookmedia/dangerzone/issues/154>.

[1] I'll inquire with others if they know of other examples like this.