macOS codesign fails with 'main executable failed strict validation'

Nuitka Version

1.1.6
Commercial: None
Python: 3.10.8 (main, Oct 13 2022, 10:17:43) [Clang 14.0.0 (clang-1400.0.29.102)]
Flavor: Homebrew Python
OS: Darwin
Arch: x86_64

Installed via pip into a virtualenv

Nuitka cli command:

python -m nuitka --onefile --output-dir=nuitka-build/build main.py

This command builds my binary perfectly fine and it runs perfectly fine. But when I try to sign it on macOS with codesign --force -s 'Developer ID...' nuitka-build/build/main.bin I get the error 'main executable failed strict validation'. After this happened I tried the following:

• Test signing a build of a simple python script which contained just print("Hello World")
• Downloaded the develop version from PyPi, use that for building, try signing again

The problem was still present afterwards.

After some searching I found a note by Apple which has some more info about that error message:

codesign says my main executable failed strict validation.

• Your Mach-O executable does not conform to modern Mach-O layout rules.
• You may be using a third party development product that hasn’t been brought up to date, or post-processed your file in unsupported ways.

Source: https://developer.apple.com/library/archive/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG309

Is there anything I should change to resolve this or is this something that needs to be updated in Nuitka?

Thanks.

[kayhayen]

This is now on the develop branch, part of the current pre-release and should be part of the immanent 1.2 release.

[kayhayen]

The onefile attaches a payload, so that is what it is complaining about. So far I think we only signed application bundles, since onefile cannot do GUI, cannot do entitlements, etc. and therefore this has not been seen.

Since recent problems with LTO and incbin, we however have a need to change the way we include binary blobs on macOS, currently for stable, it’s done via source code again. When we do it at link time again, I suppose, we can also make sure this is used on macOS as well for onefile, and then this ought to work too.