[bug] MacOS Codesign doesn't handle frameworks

[tr3ysmith]

Describe the bug

I'm developing an application on MacOS that uses a 3rd Party Framework that I package with my application. When code signing and then distributing the app, I get crash reports on boot regarding the Framework and it having discrepancies in the team id

Not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs

During my testing and research today, I found that Apple recommends signing included frameworks along with your app itself. So I tried this on the .app file, first signing the internal Framework and then signing the overall App itself and it cleared up the issue.

I'm guessing this is something that needs to be added to the bundler?

Reproduction

No response

Expected behavior

No response

Platform and versions

[✔] Environment
    - OS: Mac OS 13.2.1 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.70.0 (90c541806 2023-05-31)
    ✔ Cargo: 1.70.0 (ec8a8a0ca 2023-04-25)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (environment override by RUSTUP_TOOLCHAIN)
    - node: 18.15.0
    - yarn: 1.22.19
    - npm: 9.5.0

[-] Packages
    - tauri [RUST]: 1.4.1 (no manifest)
    - tauri-build [RUST]: 1.4.0 (no manifest)
    - wry [RUST]: 0.24.3 (no manifest)
    - tao [RUST]: 0.16.2 (no manifest)
    - @tauri-apps/api [NPM]: 1.4.0
    - @tauri-apps/cli [NPM]: 1.4.0

[-] App
    - build-type: bundle
    - CSP: style-src 'unsafe-inline' 'self'; default-src 'self'; img-src 'self' asset: https://asset.localhost; connect-src 'self' asset: https://asset.localhost
    - distDir: ../dist
    - devPath: http://localhost:3010/
    - framework: React
    - bundler: Vite

Stack trace

No response

Additional context

No response

[tr3ysmith]

#7691

[tr3ysmith]

FROM APPLE

When embedding frameworks there are two important things to note:

You must copy the framework in a way that preserves symlinks. I often see problems where folks copy a framework using cp -r, which expands the symlinks, which effectively breaks the code. I generally recommend copying code with ditto.

The notary service requires that all code be signed with a valid Developer ID, so it’s possible to build an app from components signed by different developers. My general advice, however, is that you re-sign any nested code with your Developer ID. Sign each code item separately, from the inside out.

[tr3ysmith]

Also from Apple:

Consider Deep Harmful
When signing code, do not pass the --deep option to codesign. This option is helpful in some specific circumstances but it will cause problems when signing a complex product. Specifically:
It applies the same code signing options to every code item that it signs, something that’s not appropriate. For example, you might have an app with an embedded command-line tool, where the app and the tool need different entitlements. The --deep option will apply the same entitlements to both, which is a serious mistake.
It only signs code that it can find, and it only finds code in nested code sites. If you put code in a place where the system is expecting to find data, --deep won’t sign it.
The first issue is fundamental to how --deep works, and is the main reason you should avoid it. The second issue is only a problem if you don’t follow the rules for nesting code and data within a bundle, as documented in Placing Content in a Bundle.

Wondering if we should remove the --deep command from the bundler? My guess is this may break sidecar? Maybe we need to manually sign sidecar separately?
@FabianLars

[FabianLars]

The deep flag was the main thing I had in mind when I said that the whole signing implementation is messed up on discord.
And yes, we should get rid of that flag and in theory you'd be right and it would break the sidecars but there are enough reports about the sidecar already being broken soooo there's that... but that really only means we have to do the same with the sidecars that you did with the frameworks at which point we have to think about whether there's more that needs similar treatment (example from the top of my head, what about binaries bundled via the resource feature?).

[tr3ysmith]

agreed... yeah maybe on the MacOS bundler, we need to have a configuration parameter where you can specify "binaries to sign"