Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Certain characters in the filename stop Dangerzone from working #144

Closed
micahflee opened this issue Dec 15, 2021 · 10 comments · Fixed by #181
Closed

Certain characters in the filename stop Dangerzone from working #144

micahflee opened this issue Dec 15, 2021 · 10 comments · Fixed by #181
Labels
bug Something isn't working P:mac
Milestone

Comments

@micahflee
Copy link
Contributor

It looks like the characters and prevent Dangerzone from working, as in the filename: “Wash Brains, Cleanse Hearts”_ Evidence from Chinese Government Documents about the Nature and Extent of Xinjiang’s Extrajudicial Internment Campaign _.pdf

@micahflee micahflee added the bug Something isn't working label Dec 15, 2021
@zenmonkeykstop
Copy link

Couldn't reproduce this under Linux (Ubuntu 20.04) on main - is there any specific OS under which it's failing?

@micahflee
Copy link
Contributor Author

I also can't reproduce this right now in macOS. Let me check with people who were reporting this problem recently.

@legoktm
Copy link
Member

legoktm commented Mar 22, 2022

The quoting on https://github.com/firstlookmedia/dangerzone/blob/8044f2276882e4d17570236138d024cecc80d61d/dangerzone/gui/main_window.py#L615 is suspicious, so maybe it's reproducible on Windows? (Also couldn't reproduce on Fedora 34/Qubes)

@noonespecific
Copy link

noonespecific commented Mar 22, 2022

On macOS 12.3, when running Dangerzone by double-clicking on the app, and loading a file called Оригинал.png, Dangerzone stalls and displays an empty progress bar indefinitely:

image

When launching the dangerzone gui from the terminal (/Applications/Dangerzone.app/Contents/MacOS/dangerzone), or when using the dangerzone cli (/Applications/Dangerzone.app/Contents/MacOS/dangerzone-cli Оригинал.png), in both cases dangerzone converts the file successfully.

@micahflee
Copy link
Contributor Author

I've had to debug a few issues with dangerzone where there's a difference between running the GUI app from terminal vs. double-clicking the app to run it. The difference is the environment. In the terminal, the environment is inherited from the shell, but when you double-click it, there's different environment variables.

For example, I fixed a bug like this by making use /usr/local/bin is always in the PATH environment variable, which is is when you run from the terminal, but isn't when you double-click the app:

https://github.com/firstlookmedia/dangerzone/blob/main/dangerzone/gui/__init__.py#L45-L53

For some reason I can't reproduce this on my own Mac though--it just works for me when I double-click it.

@gmarmstrong
Copy link
Contributor

I can reproduce both issues (“” and Оригинал) on macOS 12.4 (Apple Silicon) from the v0.3.1 DMG on dangerzone.rocks. It only breaks when run from Finder. However, at least as of #164, I can no longer reproduce the issue. Unfortunately, I cannot build v0.3.1 from source since PySide2 doesn't support ARM, which makes it tricky to pinpoint which revision caused this.

I've had to debug a few issues with dangerzone where there's a difference between running the GUI app from terminal vs. double-clicking the app to run it. The difference is the environment. In the terminal, the environment is inherited from the shell, but when you double-click it, there's different environment variables.

For example, I fixed a bug like this by making use /usr/local/bin is always in the PATH environment variable, which is is when you run from the terminal, but isn't when you double-click the app:

https://github.com/firstlookmedia/dangerzone/blob/main/dangerzone/gui/__init__.py#L45-L53

Worth noting that #164, since it upgrades to Qt 6, removes that "QT_MAC_WANTS_LAYER" environment variable since it will no longer be necessary. Also, does

os.environ["PATH"] = "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
intentionally omit a ":$PATH" suffix?

For some reason I can't reproduce this on my own Mac though--it just works for me when I double-click it.

I have a suspicion... @micahflee, can you reproduce the issue if you use the official https://github.com/freedomofpress/dangerzone/releases/download/v0.3.1/Dangerzone-0.3.1.dmg distribution? If so, then the build is non-deterministic. Even though PySide2 was pinned to version 5.15.2, the Qt binaries themselves are determined by whatever your Mac's Xcode SDK version was when you first created the DMG, which may have changed between December and March.

@yveszoundi
Copy link

yveszoundi commented Jun 9, 2022

@gmarmstrong, as @micahflee already found out, there's indeed a difference between double-clicking on a "Mac OS app bundle" versus running the underlying executable from the terminal (/Applications/Dangerzone.app/Contents/MacOS/whatever).

I recently encountered that very same issue my "Rust fork of Dangerzone"

  • I mitigated it via a wrapper shell script to "escape the sandbox" (invoke docker, lima or podman from the PATH): my approach could be a bit more robust though...
  • Without mitigation, even it you were to temporarily hard-code the absolute path to docker in the program, it would still fail to find it... (double-click on app bundle scenario or "open with" in Finder)

References

There are probably better approaches than my solution, I'm more familiar with Linux than other operating systems.

Approaches to the problem

Other links

@deeplow deeplow added the P:mac label Aug 8, 2022
deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 8, 2022
deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 8, 2022
deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 8, 2022
deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 8, 2022
@deeplow
Copy link
Contributor

deeplow commented Aug 8, 2022

(please ignore the above referenced commits)

The quoting on https://github.com/firstlookmedia/dangerzone/blob/8044f2276882e4d17570236138d024cecc80d61d/dangerzone/gui/main_window.py#L615 is suspicious, so maybe it's reproducible on Windows? (Also couldn't reproduce on Fedora 34/Qubes)

I was unable to reproduce this under windows (neither on v0.3.1 nor from main branch). So I guess this is a mac-specific issue as others report.

I was able to confirm all the findings above listed on an intel mac running macOS 12.0.

Even though PySide2 was pinned to version 5.15.2, the Qt binaries themselves are determined by whatever your Mac's Xcode SDK version was when you first created the DMG, which may have changed between December and March.

I don't think this is it. I can reproduce it with an intel mac running on the main branch but it only happens when I build the app bundle and execute de Dangerzone.app. If I run it via dev_scripts/dangerzone or via Contents/MacOS/dangerzone it runs well.

@yveszoundi
Copy link

It is indeed Mac OS specific issue:

  • When you double-click or run directly the "Application Bundle" (.app folder), apparently application bundles run in some kind of sandbox by default (PATH restrictions for invoking "external" programs such as Docker, etc.).
  • When the application scripts are run directly from a terminal or command prompt, my understanding is that it's literally a "sandbox escape".

deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 9, 2022
fixes freedomofpress#144: printing non-ascii characters in a macOS application
opened directly from finder would sometimes lead to an error
error message in /var/log/system.log similar to this:

  Failed to execute script 'dangerzone' due to unhandled exception:
  'ascii' codec can't encode character '\u201c' in position 1:
  ordinal not in range(128)
deeplow added a commit to deeplow/dangerzone that referenced this issue Aug 9, 2022
fixes freedomofpress#144: printing non-ascii characters in a macOS application
opened directly from finder would sometimes lead to an error
message in /var/log/system.log similar to this:

  Failed to execute script 'dangerzone' due to unhandled exception:
  'ascii' codec can't encode character '\u201c' in position 1:
  ordinal not in range(128)
@deeplow
Copy link
Contributor

deeplow commented Aug 9, 2022

I have a working fix for this. Turns out that it is this print that was causing us issues.

printing non-ascii characters in a macOS application opened directly from finder would sometimes lead to an error message in /var/log/system.log similar to this:

Failed to execute script 'dangerzone' due to unhandled exception: 'ascii' codec can't encode character '\u201c' in position 1:  ordinal not in range(128)

While I could not get exactly to the bottom of what it was happening in the first place (possibly related to the lack of encoding support on the stdout of a gui-only mac application), replacing prints with logging fixes this and should be preferred anyways, so I replaced them all and now the issue is fixed.

@micahflee micahflee added this to the 0.3.2 milestone Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P:mac
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants