feat(bundler): codesign nested code on macos

[pewsheen]

What kind of change does this PR introduce?

• Bugfix
• Feature
• Docs
• New Binding issue #___
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change?

• Yes, and the changes were approved in issue #___
• No

Checklist

• When resolving issues, they are referenced in the PR's title (e.g fix: remove a typo, closes #___, #___)
• A change file is added if any packages will require a version bump due to this PR per the instructions in the readme.
• I have added a convincing reason for adding this feature, if necessary

Other information

Related: #8075 #8173

References:

• Code Signing Tasks

Notes:

• This patch does not cover all the cases but could be a start that we can sign nested code.
• Only signs codes inside standard location (/MacOS, /Frameworks, /PlugIns, /XPCServices, /Helpers)
• The risk of the patch is that if we are trying to sign something that is not signable, then the whole process will be stopped.
• Successfully codesign and notarized the reproduced repo from [bug] Bundle fails on Apple Accelerate framework #8173 and the test.framework in tauri testing.

[lucasfernog]

I think we should take this one step forward and apply this logic to the whole .app bundle instead, so it also signs user resources and macOS custom files on v2.

[pewsheen]

I think we should take this one step forward and apply this logic to the whole .app bundle instead, so it also signs user resources and macOS custom files on v2.

After doing some article search, I think I was just reimplementing the codesign --deep, which was deprecated for reasons.

Maybe we should take other approaches to sign those files, like providing a sign_files field in tauri.config.json and letting the user fill the path, entitlements, and is_executable while we can still auto codesign the files that generate from tauri itself.

[hjmallon]

I'm really interested in solving this issue (probably in 1.x branch since it is for a live project). Would we rather have code signing on macOS:

1. Where the main app is automatically signed as currenlty, but all ofher files need a config line like @pewsheen says?
2. Something that does a --deep equivalent on everything, which is not very fine grained as mentioned?
3. Something that does a --deep equivalent on everuthing, but with a new config key for arguments for non standard parts?
4. Something else?

[raphaelmenges]

Maybe we should take other approaches to sign those files, like providing a sign_files field in tauri.config.json and letting the user fill the path, entitlements, and is_executable while we can still auto codesign the files that generate from tauri itself.

Perhaps I overlook it in the documentation, but I am facing this exact issue and you could point me out to such sign_files field - if it exists. I am bundling a .dylib with my application that must be signed alongside the Tauri binaries to pass the notarization. Right now, notarization fails with "The binary is not signed with a valid Developer ID certificate." for that .dylib.

Worst case I can code sign the .dylib manually, yet, I of course prefer a Tauri-based solution.

[therealpurplemana]

Did you find a solution to this? I'm running into this also.

[raphaelmenges]

No, still a problem to my knowledge. I plan to use https://github.com/lando/code-sign-action to sign the .dylib manually. I would highly prefer to let the complete signing happen via Tauri.

[therealpurplemana]

This isn't great. It's causing issues with onnx and opencv libraries if you want to make release builds using them. Isn't there a way to disable the unsafe library check and it still passes notarization?

[raphaelmenges]

I found some workaround using the feature to add "frameworks" in the tauri.conf.json: #12001 (comment)

[therealpurplemana]

I found some workaround using the feature to add "frameworks" in the tauri.conf.json: #12001 (comment)

This is exactly how I solved it also. If you specify dylibs in Frameworks, Tauri will a) code sign it, b) properly @rpath it into the Frameworks folder. I can confirm it passes Apple Notarization also and suspect even Gatekeeper.