Installation via homebrew doesn't start the application (macOS)

[deeplow]

Application crashes as soon as it's started. If ran from the terminal, it shows the following:

$ /Applications/Dangerzone.app/Contents/MacOS/dangerzone
[70056] Error loading Python lib '/Applications/Dangerzone.app/Contents/MacOS/libpython3.11.dylib': dlopen: dlopen(/Applications/Dangerzone.app/Contents/MacOS/libpython3.11.dylib, 0x000A): Symbol not found: _mkfifoat
  Referenced from: /Applications/Dangerzone.app/Contents/MacOS/libpython3.11.dylib
  Expected in: /usr/lib/libSystem.B.dylib

[apyrgio]

I've tried to reproduce this in a Mac system, both Intel and M1 architectures, but I don't see this error. I believe this may be related to the way Python is installed in the machine you're working on.

[deeplow]

We were unable to reproduce in another machine. Closing it for now.

[Ecordonnier]

I see this error on MacOS 12.6.8 (on a completely unrelated piece of software). I think it's due to the MacOS version.

[deeplow]

Ah. So maybe it could be an issue with homebrew itself? 🤔 or just simply macOS. Since the version was pretty outdated we didn't invest many efforts in finding this bug.

[Ecordonnier]

My guess is an incompatibility between some pyinstaller versions/parameters and some macos versions.

[maltfield]

Was there any fix for this? I came across this thread googling the error message. We just found that our GitHub-Actions & PyInstaller-built app also doesn't work for older MacOS systems :(

[maltfield]

I wanted to contribute to see if I could reproduce the issue, but I couldn't see any secure way to download dangerzone on MacOS (brew is notoriously insecure), so I opened this ticket about it:

• Sign releases on github #761

[apyrgio]

Was there any fix for this?

No actually, we couldn't reproduce it. If you have found what's the underlying cause, feel free to share!

[maltfield]

@apyrgio Did you try running your MacOS release of dangerzone on MacOS 10.x (Catalina) or older?

At least for our MacOS builds of buskill, it appears that this issue was caused by using the brew-installed version of Python to build releases with PyInstaller, which will make builds only work for the OS X version that it was built-on (and higher).

I've read that if you build with the python.org release of python (as opposed to the brew one), then it will support OS X versions as old as (iirc) 10.x

I think you can see what minimum OS X version your app will support by running this on the python binary that is used to build it:

sudo otool -L /path/to/python3

Check for minos in the output.

See also:

• Fix Builds (python_gnupg-0.5.2-py2.py3-none-any.whl.asc 404 not found) BusKill/buskill-app#78 (comment)
• https://github.com/orgs/pyinstaller/discussions/6316
• https://pyinstaller.org/en/stable/bootloader-building.html#building-for-macos

[maltfield]

@deeplow are you still able to reproduce this bug? Can you send us the full command output of sw_vers on your system where this error occurs?

[apyrgio]

Oh, that's very cool! I don't have such a macOS system at hand, but I can check the command you mentioned against the Python library that gets bundled with the app, and the system one.

[apyrgio]

Hey @maltfield, sorry for the late reply. I checked out the links you provided, thanks for those.

First of all, the system where we build Dangerzone is a macOS one (Ventura). So, we don't cross-compile as you folks with BusKill do (at least, judging from BusKill/buskill-app#78).

Now, let's take a look at the bundled Python3 version in the Dangerzone application:

$ otool -l /Applications/Dangerzone.app/Contents/Resources/libpython3.11.dylib | grep minos
    minos 13.2

And the system one (provided by Xcode):

$ otool -l /usr/bin/python3| grep minos 
    minos 13.5

I'm pretty sure we have users that have installed Dangerzone in versions < Ventura, so I think that minos is not a good indication for app compatibility. That being said, I haven't dug deep into it, so I may be wrong.

[maltfield]

I'm pretty sure we have users that have installed Dangerzone in versions < Ventura

well, I have a Mac Mini running macOS v10.15.7 (catalina), which I'll happily use to test dangerzone, once it's signed with PGP.

we don't cross-compile as you folks with BusKill do

We build on GitHub's free macOS runners. We're also sponsored by MacStadium, who gives us a free Mac Mini. It's an older Mac Mini that can't be updated beyond macOS 10.x (catalina). We use this older system to test & debug the app.

Recently our builds broke. We were able to fix it by bumping-up the dependencies. Now we're building BusKill using Python 3.12 on a GitHub Runner running pinned to macOS 13 (ventura). So this is the same as you.

I encountered the same error listed in this ticket's OP when I tried to run the BusKill build from our the GitHub Runner's macOS 13.x (ventura) system on our macOS 10.x (catalina) system.

At this time we're still trying to figure out the cause & solution, but I'm thinking it will be resolved by switching from the brew-provided python to the python.org-provided python.

[apyrgio]

well, I have a Mac Mini running macOS v10.15.7 (catalina), which I'll happily use to test dangerzone, once it's signed with PGP.

Aaand here you go: #761 (comment)

[maltfield]

I am able to reproduce this bug.

On a Mac Mini running 10.15.7, I downloaded Dangerzone v0.6.0, verified it, opened the .dmg, and opened dangerzone.

open Dangerzone-0.6.0-i686.dmg
open /Volumes/Dangerzone/Dangerzone.app/Contents/MacOS/dangerzone

Instead of the Dangerzone app opening, a terminal with the following contents appears:

Last login: Fri Apr 12 06:18:54 from OBFUSCATED
user@host ~ % /Volumes/Dangerzone/Dangerzone.app/Contents/MacOS/dangerzone ; exit;
[78594] Error loading Python lib '/Volumes/Dangerzone/Dangerzone.app/Contents/Frameworks/libpython3.11.dylib': dlopen: dlopen(/Volumes/Dangerzone/Dangerzone.app/Contents/Frameworks/libpython3.11.dylib, 10): Symbol not found: _mkfifoat
  Referenced from: /Volumes/Dangerzone/Dangerzone.app/Contents/Frameworks/libpython3.11.dylib (which was built for Mac OS X 13.2)
  Expected in: /usr/lib/libSystem.B.dylib
 in /Volumes/Dangerzone/Dangerzone.app/Contents/Frameworks/libpython3.11.dylib

[Process completed]

[maltfield]

I can confirm that I was able to fix this same error message in my own app (BusKill) by switching from using the brew-supplied python-3.12 release to the python.org-supplied python-3.12 release (.pkg file).

I recommend attempting to build Dangerzone with the python binary that comes from python.org to make Dangerzone work on older MacOS systems.

You can download the python.org version of Python here (note that it's signed with PGP)

• https://www.python.org/downloads/macos/

You can install it with the following command

sudo installer -pkg path/to/python.pkg -target /

After that, you can use the binary installed to /usr/local/bin/python3 to build your Dangerzone app. The resulting binary should no longer have this error when executed on older MacOS platforms.

[apyrgio]

Reopening this issue, based on Michael's research (thanks a bunch!). I'm adding this to our hotfix milestone (0.6.1), and the target should be to:

1. Update the macOS section of our RELEASE.md document (https://github.com/freedomofpress/dangerzone/blob/main/RELEASE.md#macos-release), and explicitly mention installing/updating Python from python.org.
2. Build macOS binaries for Dangerzone on 0.6.1 using the new instructions.
3. Verify that our macOS binaries can be installed in macOS 10.

[apyrgio]

Quick heads up: a macOS user on Monterey 12.7.4 also encountered the same issue: #783 (comment).

[apyrgio]

Dangerzone 0.6.1 is out 🥳 . If any of you folks are still affected by this issue, we suggest giving the new build a spin.

[maltfield]

@apyrgio I no longer get the previous error (complaining about libpython3.11.dylib) when trying to execute Dangerzone 0.6.1.

Unfortunately, I get this error instead:

Sorry, "Dangerzone" cannot be run on this version of macOS. Qt requires macOS 11.0.0 or later, you have macOS 10.15.7.

So it does appear that you squashed this bug by switching to the python.org version -- only to uncover another bug.

I don't use Qt in my app, so I don't know the resolution here. Sorry.

[apyrgio]

Nice, thanks a lot for checking it out Michael. I'm ultimately ok with this limitation, since this macOS version no longer gets updates.

I think we can mark this issue as resolved. However, if anyone else is in macOS 11/12 and still experiences this issue, feel free to chime in.

[maltfield]

As a Linux user this is hard to fathom, but I think it's important to mention: I literally cannot upgrade macOS to a newer version.

Apple says I need to buy a newer machine in order to run macOS 11 🤦 My machine is an old MacMini in the cloud that I get for free from MacStadium for testing FOSS. And surely there's many Apple users with old desktops or laptops who can't afford to upgrade to the latest hardware.

I think it's important to support users who have fully updated to the latest version that they're able to upgrade-to. But I do understand there has to be a cut-off somewhere. I just wonder how many at-risk folks wouldn't be able to use Dangerzone because of this.

[apyrgio]

For sure, I have friends who were pressed into a similar situation, and had to upgrade their hardware when they were low on funds. In a different context, I'd share my frustration over Apple's device deprecation policy, but this issue is not the time and place.

From a maintainer's perspective though, I see lots of stuff that need to be done to make Dangerzone safer and more accessible for existing and new users. It's hard to measure the net impact of our choices when working on an open-source project, but for this specific limitation, it seems to me that it's low and, most importantly, the effort to fix it would be high. It would require fixing (convincing?) Qt to support older macOS versions, when even macOS 11 is EOL (oh come on Apple).

I understand that it's a choice that does not help affected users. If a person is affected, a workaround I can think of is to run Dangerzone in a Linux VM. This way, they will stay up-to-date, irrespective of their OS. And of course, please open an issue, so that we can understand how may are affected and prioritize accordingly.