[feat] Use ad-hoc code signing on macOS if no certificate is provided

[FabianLars]

Describe the problem

adhoc code signing the app will result in aarch64 binaries behaving like x86_64. This means you'll get rid of the "app is damaged" dialog and then proceed to open the app via right click -> open (double click still won't work without a proper cert)

Describe the solution you'd like

codesign -s - appname

Alternatives considered

None, we should just do it 🤷

Additional context

No response

[pewsheen]

Hmm.. I think it could be done by setting "signingIdentity": "-" in tauri.config.json?

Updated A quick test on my MacBook without specifying signingIdentity. Looks like it signs with ad-hoc by default?

> codesign -dv /Users/jason/Documents/tauri-apps/issues/adhoc-test/src-tauri/target/release/bundle/macos/adhoc-test.app
Executable=/Users/jason/Documents/tauri-apps/issues/adhoc-test/src-tauri/target/release/bundle/macos/adhoc-test.app/Contents/MacOS/adhoc-test
Identifier=adhoc_test-fec55f21a013f289
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20400 size=77620 flags=0x20002(adhoc,linker-signed) hashes=2422+0 location=embedded
Signature=adhoc # <<
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

[thewh1teagle]

Hmm.. I think it could be done by setting "signingIdentity": "-" in tauri.config.json

It works! Very useful for simple projects that don't intend to sign it with an Apple certificate, as otherwise, the aarch64 binary won't open at all.

[FabianLars]

good to know! Maybe we should change the template to include an empty string for that then? Or well, i'd still prefer to do that in tauri directly if no config is provided.

[pewsheen]

I see that doing it in Tauri directly is fine since it's already an ad-hoc signature by default; just maybe increasing the build time?

[thewh1teagle]

You can apply it only if OS is darwin and ARCH is aarch64 because on x86_64 it's not neccesery

[thewh1teagle]

@pewsheen

Hmm.. I think it could be done by setting "signingIdentity": "-" in tauri.config.json?

Updated A quick test on my MacBook without specifying signingIdentity. Looks like it signs with ad-hoc by default?

I found that if I include frameworks in the bundle for macOS while use signingIdentity: "-" then the signature of the binary is different from the frameworks, as a result the program crash with error:

crash.log

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------

Process:               vibe [9728]
Path:                  /private/var/folders/*/vibe.app/Contents/MacOS/vibe
Identifier:            github.com.thewh1teagle.vibe
Version:               0.0.7 (20240331.130136)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501

Date/Time:             2024-03-31 17:32:41.6653 +0300
OS Version:            macOS 14.2.1 (23C71)
Report Version:        12
Anonymous UUID:        7A186555-****-****-****-8A9E775EA360

Sleep/Wake UUID:       9F619295-****-4F84-****-B8A41CF97584

Time Awake Since Boot: 54000 seconds
Time Since Wake:       509 seconds

System Integrity Protection: enabled

Crashed Thread:        0

Exception Type:        EXC_CRASH (SIGABRT)
Exception Codes:       0x0000000000000000, 0x0000000000000000

Termination Reason:    Namespace DYLD, Code 1 Library missing
Library not loaded: @rpath/libavcodec.60.dylib
Referenced from: <77478CF6-E9C0-3A8B-ABAC-C2A865347C92> /private/var/folders/*/vibe.app/Contents/MacOS/vibe
Reason: tried: '/private/var/folders/sz/4_ymp61s34jdxsgqgtbrs3vh0000gn/T/AppTranslocation/8332B0A9-7A6C-4F94-8342-6D9F8D2C6B89/d/vibe.app/Contents/Frameworks/libavcodec.60.dylib' (code signature in <58B6E688-46CD-3B8B-ABCD-648EDE79FFA5> '/private/var/folders/sz/4_ymp61s34jdxsgqgtbrs3vh0000gn/T/AppTranslocation/8332B0A9-7A6C-4F94-8342-6D9F8D2C6B89/d/vibe.app/Contents/Frameworks/libavcodec.60.dylib' not valid for use in process: mapping process and mapped file (non-platform) have different Team IDs), '/private/var/folders/sz/4_ymp61s34jdxsgqgtbrs3vh0000gn/T/AppTranslocation/8332B0A9-7A6C-4F94-8342-6D9F8D2C6B89/d/vibe.app/Contents/Frameworks/libavcodec.60.dylib' (code signature in <58B6E688-46CD-3B8B-ABCD-648EDE79FFA5> '/private/var/folders/sz/4_ymp61s34jdxsgqgtbrs3v
(terminated at launch; ignore backtrace)

action log

Update

I found the exact line which cause that problem - tooling/bundler/src/bundle/macos/sign.rs#L210 It signs the final executable with --options runtime which add per codesign's man page:

     runtime  On macOS versions >= 10.14.0, opts signed processes into a
              hardened runtime environment which includes runtime code signing
              enforcement, library validation, hard, kill, and debugging
              restrictions.  These restrictions can be selectively relaxed via
              entitlements. Note: macOS versions older than 10.14.0 ignore the
              presence of this flag in the code signature.

If I re-sign the executable with codesign with codesign -f -s - ./name.app/Contenet/MacOS/name then it remove the runtime flag which tauri set and then it can run while loading another shared libraries (dylib files)