Non-cach-o files sign return error(invalid magic number) and some nested bundle sign issue.

[Yuuon]

Hi there, Currently we're working on moving all our code sign steps on Linux machine for automated build pipeline, including mac app and installer. It's great to have this tool can work under Linux to do this, however, I met some issues.

First one is related to this: https://github.com/indygreg/apple-platform-rs/issues/87, I've add a commnet which mentioned that it's still not working in my case, which the installer's MacOS folder contains an osx-x86_64 Mach-o file, and a script(which used to judge current platform), the code sign will return error: Error: binary parsing error: Invalid magic number: 0x23212f62.

Second issue is about our application, which used 3rd party plugins, so there are nested bundles need to sign. I do tried "Just sign once for the AppName.app", "First sign the nested bundle inside the app, then sign from the outter app"(I also tried to sign the .framework bundle but it give error when do the code sign), the code sign step itself doesn't give any error back, but it cannot pass the notary which gives "The executable does not have the hardened runtime enabled." or "The signature of the binary is invalid." for nested Mach-o file in the nested bundle.

Any advice for these two issues?

Using version: 0.27.0

[Yuuon]

ok, for application, I've somehow fixed the nested bundles, but now the Mach-o file for main application cannot pass the notarization. I've tried sign the Mach-O file with runtime flag separately(before there is a nested app bundle and that one seems work(ZFBrowser, a in-game browser for Unity) after I signed it separatedly), using the "--for-notarization" flag, additional-binary by command:

rcodesign sign \
--p12-file p12file.p12 --p12-password-file pass.txt \
--code-signature-flags runtime \
--code-signature-flags AppName.app/Contents/Frameworks/ZFGameBrowser.app/Contents/MacOS/ZFGameBrowser:runtime \
AppName.app

but it still returns "The signature of the binary is invalid." error.

Currently I'm trying to check signature info as debug & report section recommanded, but I didn't get the point when comparing with the files I previously signed and worked on Mac.

Update: For application, I find one difference for main Mach-O file between the one I manually signed on Mac and the one signed with this tool, it's about the entitlement info -- before we manually add the entitlement info during the code sign, but now there is no such thing when I use rcodesign -- I guess there is a default one in use, but I'm wondering why it doesn't added to the main Mach-O file. Also, if I want to manually target a custom entitlement file, I need to use the config file, but I didn't find one under $HOME/.config(because I didn't use cargo to install the tool, but just unzip the release package from github?) -- what should I do about this? Is there a template of this config I can modify, or just a blank file and write in the preferences I need will do?

for installer, I tried only sign the Mach-O file, by using command:

rcodesign sign --for-notarization \
--p12-file p12File.p12 --p12-password-file pass.txt \
--code-signature-flags runtime \ 
Test_Mac_Installer.app/Contents/MacOS/osx-x86_64

 rcodesign notary-submit \
--api-key-file appstoreconnectkey.json \
--staple \
Test_Mac_Installer.app

The notarization worked, it returns accepted, but the staple step still give an error of Error: binary parsing error: Invalid magic number: 0x23212f62

[Yuuon]

OK, I've fixed those issues by some tricky ways. Noted here if some met the same issue. For installer, we analysed that script, considering it won't do any harm if we remove it, so we remove that script, and modify the pInfo.list file, where defines which file to execute when MacOS run the application. -- It doesn't solve the issue, but just a workaround for me. And for the viewer application, the issue blocking the notarization is actually "case sensitvie", so we're trying to notary the Mac build under Linux for a Unity build, and from 2020(I guess), their folder for plugins is actually "PlugIns", "I" in upper case, while all other platform is still using "Plugins", however, some plugins, might be the version outdated, are still using "Plugins" for Mac path, so, e.g., when a post build method trying to copy some files to the plugins folder, under Linux, it will send into the Plugins folder, which separated from "PlugIns". And then things became easier to understand, on linux there is two folder, but on Mac OS, it becomes one, the file structure changed, and also maybe the code sign get overwritten, so in the end, failed. As the tools is for cross-platform notarization, I guess Linux will be a common solution, so case sensitve should really a checkpoint for every one, recommend to add some notes in docs. The script under MacOS is still an issue though, hope it can get solved.