I tried to convert a pdf file which is password protected / encrypted,
dangerzone didn't ask me for a password and failed with:

Separating document into pages
Separating document into pages failed: None

The window icon isn't working in Windows

The window icon isn't loading properly in Windows.

Also, building the container fails because the path seems to get built wrong for Windows paths.

Right now the issue is the version of python3 isn't new enough, but the package can depend on python3.7 instead.

When you right-click on a document and try opening with dangerzone, it seems to immediately crash

For both Windows and Mac, there are various issues with automatically installing and launching Docker Desktop.

Instead, if it's not installed, it should download it for you in ~/Downloads and tell you to install it.

If it is installed, it should tell you to open it in the background.

Right now, the output from the unprivileged scripts gets suppressed, so if there's a crash, you can't see the stacktrace. We should stop suppressing it, and instead fix the code so it shows less warnings.

I believe it started failing when I switched to dropping privileges in the container

At the moment the only hardening that the container does is running the conversion logic as a non-root user. There needs to be more work in this area. From this comment #44 (comment):

@micahflee i saw this on hacker news earlier. thank you for working to build some new tooling for dealing with a pretty unreliable format in a system that looks to be pretty easy to use.

with a tool like this that is meant to handle potentially hostile data, i believe it is important to explain the threat model for this tool in the README, similar to projects like qubes and whonix. people can hurt themselves trusting a tool without understanding what threats it is actually meant to protect them against and what the attacks against the system are.

in this current proof of concept, dangerzone is expecting a lot out of docker's default configuration, with the only change i saw from a default docker run being to disable network access. this leaves a lot of attack surface up to default configurations, and i believe that tool advertised to handle hostile data should be built with a pretty paranoid threat model in mind.

for a targeted or relatively sophisticated adversary class, a docker container in a relatively default state should be best assumed a fragile security boundary to start. there's a good amount of hardening that can still be had. this is a rabbit hole of hardening for sure; there are hardware resource constraints that can be placed on the container for denial of service, sign the default image, use various --security-opt features such as no-new-privileges (easy) or seccomp for syscall whitelisting, to name a few.

in my opinion, parts of the cis docker benchmark and the above documentation is a good minimum baseline to target and explain in the threat model.

Right now dangerzone will run in macOS from the source tree, but I need to add actual Mac packaging to create an app bundle and an installer pkg. The app bundle should register itself to be able to open pdf, docx, etc. file formats.

Also while I'm at it, it would be cool if I can turn on the macOS sandbox. The tricky part is needing to be able to subprocess to docker and open, and also being able to read and write to the correct places in the filesystem. But if I can make it work, that would be great. Dangerzone itself doesn't need network access, too -- only docker does to pull the container.

After downloading the .msi for Windows and run it, we get this:

It seems to install fine when we click "Run Anyway," but I thought I should let you know

I have spent some time in the development environment today to see how hard it would be to build deb variants for Ubuntu 18.04 and derivatives. After filing a few pull requests for minor fixes and testing out if earlier versions of dependencies, that are native in 18.04 mainline, worked - I have come to the conclusion that dangerzone does indeed work as my minimal testing has yielded.

When building the deb using the out of the box installer I did the following...

1. Ran build_deb.py.
2. Extracted the contents of the compiled deb file in deb_dist folder: dpkg-deb -R dangerzone_0.1.1-1_all.deb tmp
3. Modified two files in the tmp/DEBIAN folder: control and postinst.
4. Modify single line in control to: Depends: python3:any (>= 3.6~), ...
5. Modify single line in postinst to: py3compile -p dangerzone -V 3.6-
6. Rebuild deb from the deb_dist folder root: dpkg-deb -b tmp dangerzone_0.1.1-1_all-modified1804.deb
7. Install the deb: dpkg -i dpkg-deb -b tmp dangerzone_0.1.1-1_all-modified1804.deb.

Again - I've only tested this minimally, but it does appear to work as expected. It might be beneficial for many users to have Bionic Beaver available for use since this is likely the most widely deployed Ubuntu distribution at the current time.

It looks like it has a learning curve, but I think I should make an MSI using WiX Toolkit https://wixtoolset.org/

More info: https://stackoverflow.com/a/49632260

If going to Open With > dangerzone to open a file while dangerzone is not already running in the background, dangerzone launches and then promptly crashes. If dangerzone is already running in the background, the file loads in dangerzone as per the usual.

The README doesn't actually say what this protects against. I can imagine some things, but without a list, you are either left not understanding why you would even need this, or you are left with a false sense of security thinking you are protected against things you are not protected against.

For example, here is a list of dangers that may or may not be included:

• memory exhaustion
• remote tracking over a network
• macros
• other unexpected file system/resource access (what exactly?)
• hidden messages in alpha channels
• hidden messages in lower bits of images
• improperly scrubbed data still present "underneath" (for vector based formats)
• more??

Related to #11

Once https://github.com/firstlookmedia/dangerzone-converter/issues/1 is finished, we need to make sure the app registers itself as a program that can open these MIME types.

For Linux, that would be in the .desktop file here: https://github.com/firstlookmedia/dangerzone/blob/master/install/linux/media.firstlook.dangerzone.desktop#L10 -- I'm not sure where in macOS yet.

Using dangerzone on a big pdf file with 243 pages results in a timeout for the compression in ps2pdf. Everything else seems to work fine. I suggest to increase the timeout or calculate it based on the page count, since smaller pdf files wont take that long to compress in contrast to bigger pdf files.

https://github.com/firstlookmedia/dangerzone-converter/blob/master/scripts/pixels-to-pdf-unpriv#L125

Merging 243 pages into a single PDF
Compressing PDF
Error compressing PDF, ps2pdf timed out after 60 seconds

There should be a flag like --no-gui which requires a filename to be passed in, will skip opening a GUI, and will automatically do the conversion and save the file. This will allow dangerzone to be more easily used in scripts.

It looks like there are more differences between docker and podman that need to be handled. Specifically, while document-to-pixels works in docker, it fails with this error in podman.

root@e80fd5b9b501:/# sudo -u user /usr/local/bin/document-to-pixels-unpriv 
sudo: unable to resolve host e80fd5b9b501: Temporary failure in name resolution 
Traceback (most recent call last): 
  File "/usr/local/bin/document-to-pixels-unpriv", line 219, in <module> 
    main() 
  File "/usr/local/bin/document-to-pixels-unpriv", line 89, in main 
    mime_type = mime.from_file("/tmp/input_file") 
  File "/usr/lib/python3/dist-packages/magic/__init__.py", line 96, in from_file 
    with _real_open(filename): 
PermissionError: [Errno 13] Permission denied: '/tmp/input_file' 
root@e80fd5b9b501:/#  

Just like this has been ported to macOS, it should be easy enough to port to Windows using Docker for Windows.

When trying to dl and install docker (via Docker for Windows Installer.exe), I keep getting the following error message: Installation failed: one prerequisite is not fulfilled. Docker Desktop requires Windows 10 Pro or Enterprise version 15063 to run.

It's possible to install podman in Ubuntu or Debian (here are good instructions) but you have to build it from source, it isn't packaged. However, docker is packaged.

To make packaging simpler, the Debian/Ubuntu version of dangerzone should use docker, and the Fedora version should use podman.

Build from source

If you'd like to build from source, follow the build instructions.

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

If it's not installed, prompt the user to install it, or maybe help the user install it automatically.

Right now it just assumes it can subprocess docker commands.

In macOS, dangerzone should be able to be open without any windows. And when it receives a file open event, it should open a new separate window for each event.

To make testing things simpler, the dangerzone repo should contain a folder full of documents of different formats to test with

dangerzone fails to install (in Ubuntu 19.10 at least) when Docker is installed through the docker.com repositories.

Steps:

1. Install Docker CE following these instructions.
2. Try to install Dangerzone following the wiki (Ubuntu instructions).

Expected: Dangerzone installs just fine.

Got: error because docker.io package cannot be installed (it conflicts with docker-ce):

$ sudo apt install dangerzone
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 dangerzone : Depends: docker.io but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

This will be tricky, but I think possible!

Here's some relevant documentation:

• Podman remote client: https://github.com/containers/libpod/blob/master/docs/tutorials/remote_client.md
• Podman Mac client: https://github.com/containers/libpod/blob/master/docs/tutorials/mac_client.md

Basically, the podman Mac client is the remote client built for macOS. The remote client allows you to use podman on a remote Linux system, either virtual or physical. So the tricky part is, how can I bundle a Linux virtual machine with the Mac version of dangerzone?

Here's how Docker for Mac does it: http://collabnix.com/how-docker-for-mac-works-under-the-hood/

Specifically, it uses a LinuxKit VM and HyperKit as the native Mac hypervisor.

So for dangerzone to work in Mac, I'll need to figure out how to make a Mac package that containers Hyperkit, a LinuxKit VM with podman installed in it, and a podman remote client, configured to connect remotely to the VM to run the actual containers.

Note that the podman remote client docs say:

First and foremost, the remote-client is under heavy development. We are adding new commands and functions frequently. We also are working on a rootless implementation that does not require privileged users.

So, it may not be possible to run all of podman as the unprivileged user on Mac at this point.

Right now everything in the container runs as root. I didn't think this was much of an issue when podman runs as an unprivileged user on the host. However, now that the Mac and Windows version use Docker, it would be good to take steps to harden the container more.

The only issue with creating an unprivileged user in the container and running code as that is that it needs to be able to have permission to write to the mounted volume.

Maybe this can be solved by:

• Creating an unprivileged user in the container
• Creating a wrapper script
• Running the wrapper script as root, which then drops privs to run the actual conversion script, and when that's done uses root to copy the files into the volume

If the user is not in the docker group, right now dangerzone makes the user add themselves to the docker group before it will work. But being able to use docker without a password introduces a privilege escalation issue -- anyone that can run commands as your user can easily get root without your password.

Instead, if your user is not in the docker group, it should execute container commands using /usr/bin/pkexec and have the user type their password. If the user is in the docker group, it should just let them do it without a password.

This requires figuring out how to find a list of installed PDF readers in Windows

App crashed immediately on startup when attempting to open. Behavior is consistent whether attempting to open on its own, or using "Open With" dialog on PDF.
Console shows application exiting with a code 255, and sometimes with a code 2.

Running Mojave 10.14.6. Cons

If there is no dangerzone container, then updating the container is already checked (and the checkbox is disabled, because it's required).

It should also be required every time a user updates dangerzone (in case the Dockerfile has been updated).

It shouldn't be required, but should be checked by default, if the container hasn't been updated within the last month.

Otherwise, it should be unchecked by default.

In order to enable easy development/testing on GNU/Linux it would be cool to have a flatpak manifest. You could then also submit the app to Flathub.

When pulling the container image, it displays stdout in the GUI. However, when you run docker pull flmcode/dangerzone the output is way more informative, showing you the different chunks and progress bars for each one. I'd like to make the GUI show the same.

It should handle this smoothly, and offer to restart the docker service for you

Download and install dangerzone successfully. However, when launch it, I just get the fatal error. Is there missing something? Thanks and Regards

When converting a large document (in my case 105 pages), it fails on page 20 on the "from pixels to searchable PDF"-step.

Im using this PDF from Acronis

For the life of me I can't seem to create a pull request for a wiki ¯\_(ツ)_/¯
In Installing-Dangerzone the link for building from souce:

If you'd like to build from source, follow the [build instructions](https://github.com/firstlookmedia/dangerzone/blob/develop/BUILD.md).

should reference master not develop:

If you'd like to build from source, follow the [build instructions](https://github.com/firstlookmedia/dangerzone/blob/master/BUILD.md).

Installs fine but does not open when you click on the icon on macOS Mojave.

I am looking to provide dangerzone as a default application on the Librem 5 phone hardware (running PureOS, which is based off of Debian Buster). As the dangerzone package is architecture-independent I have been able to install the buster Debian package and run it on the phone (it doesn't quite fit on the default small screen resolution but I'm working on a PR to help with that).

Unfortunately the only docker image that is provided is for amd64. This causes docker to fail on platforms that don't support amd64. Please provide an alternate docker image built for arm64 platforms.

Need to make sure the subprocesses hide the terminal window

Instead of building it manually

The user's PC can be infected even before converting the document via dangerzone.
If the previews/thumbnails are not disabled in the OS, then all the malicious stuff will run even before sanitizing the document with dangerzone.

Therefore it would be necessary for the users to disable previews/thumbnails in the OS even before downloading any files.

There is a vulnerability in Windows which is already actively exploited in the wild.
Here is the advisory from Microsoft, and the steps to disable these vulnerable OS features:

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV200006