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.