Heeey, when I just downloaded the dmg and opened Pyzo from there, I got

So it looks like it worked??

Aha, it looks like when the app is packged in a dmg, it works, but not when packaged in a zip file. Perhaps some of the signing info is lost when it's zipped?

I did all my testing by downloading the zipfile, so it might have worked in a much earlier point in my struggles 😆 😢

On macOS 10.14.5 and later it is also required that the software gets "notarized" by Apple. Basically the signed app gets sent to Apple for an automated malware scan. See also https://developer.apple.com/developer-id/ for some info. I think the missing notarization is what's causing the malware warning dialog.

This process is a bit more difficult to automate, but have a look how we handle that for MusicBrainz Picard at https://github.com/metabrainz/picard/blob/master/scripts/package/macos-notarize-app.sh

@phw The notarization is done in the action :) - but thanks for the link, good to see alternative solutions.

To be clear, the application distributed in the .dmg now works correctly, without warnings. The weird thing is that the one distributed in a zip-file still gives the warning, even though it contains the exact same pyzo.app. My guess is file attributes get lost during the zipping.

What about a tar file? tar preserves file permissions unlike zip. Also does your application contain symlinks? zip removes them by default too. Try zip's -l flag.

My guess is file attributes get lost during the zipping.

Oh yes, that's the likely cause then. I can only recommend to avoid signatures being put into file system attributes. If you do this you will get random complaints of users about a broken app. File system attributes can for example also be lost if users move the app folder onto a file system that does not support them.

To avoid the file signatures in attributes all files that cannot be signed as part of the file itself should be put into the Resources folder instead of Contents/MacOS.

See also my comment on pyinstaller/pyinstaller#7180 (comment)

To avoid the file signatures in attributes all files that cannot be signed as part of the file itself should be put into the Resources folder instead of Contents.

That's what I do now. (if you mean Contents/Resources vs Conrtents/MacOS).

What about a tar file? tar preserves file permissions unlike zip. Also does your application contain symlinks? zip removes them by default too. Try zip's -l flag.

I tried preserving symlinks with .zip, as well as using a .tar.gz, and in both cases I still get the warning. I'm not too worried, since by far most users will use the .dmg. Though if you have more ideas, I'll give it a shot.

Thx @almarklein Thought I posted some of our methods as well,

We (UltiMaker Cura) had to change stuff a bit more extensive, doing some duck typing, to ensure that our files are stored to the correct locations: https://github.com/Ultimaker/Cura/blob/5970524b3a6dca81c83156d9c48c65facb9481ba/UltiMaker-Cura.spec.jinja#L72 This jinja template is filled out with our dependency manager Conan here: https://github.com/Ultimaker/Cura/blob/5970524b3a6dca81c83156d9c48c65facb9481ba/conanfile.py#L183

Code signing and notarizing is done in this workflow: https://github.com/Ultimaker/Cura/blob/main/.github/workflows/cura-installer.yml

Which basically uses the scripts in this folder: https://github.com/Ultimaker/Cura/tree/main/packaging/MacOS