-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bug] MacOS - Codesigning and notarization issue when using ExternalBin #11992
Comments
Digging deeper into the issue. I verified the signature for each binary separately. The custom (hello world) binary is showing valid but the tauri created binary gives the following output src-tauri/target/release/bundle/macos/binary-app.app/Contents/MacOS/binary-app: nested code is modified or invalid
file modified: /Users/gilles/_git/binary-app/src-tauri/target/release/bundle/macos/binary-app.app/Contents/MacOS/test_binary indicating that the Nested binary is invalid or modified in some way Executable=/Users/gilles/_git/binary-app/src-tauri/target/release/bundle/macos/binary-app.app/Contents/MacOS/binary-app
Identifier=com.binary-app.app
Format=app bundle with Mach-O thin (arm64)
CodeDirectory v=20500 size=87795 flags=0x10000(runtime) hashes=2737+3 location=embedded
VersionPlatform=1
VersionMin=720896
VersionSDK=983552
Hash type=sha256 size=32
CandidateCDHash sha256=e7ce8c154244084fcf1856b471de764fbeaa0929
CandidateCDHashFull sha256=e7ce8c154244084fcf1856b471de764fbeaa0929a3e1bf1f153411a4534696a9
Hash choices=sha256
CMSDigest=e7ce8c154244084fcf1856b471de764fbeaa0929a3e1bf1f153411a4534696a9
CMSDigestType=2
Executable Segment base=0
Executable Segment limit=7880704
Executable Segment flags=0x1
Page size=4096
-3=274b12c645b0c4079531952092365c49608901ffdb808ef8d2079b54e9e5e01a
-2=eb75a570d13e455eae9cd234f3b33d568735be28af7c0904f5296dbee092650f
-1=173ed60f95aecc0289ad217a4e73e8b6afcaa71e6c8c8f9e59a803d031f86d29
0=0f5924f06b355ee2d23b49772c22a6967ece8380f1d15f6bc9940df14fa5a8f7
1=ad7facb2586fc6e966c004d7d1d16b024f5805ff7cb47c7a85dabd8b48892ca7
2=fa2e4c2e36a5308506a2c5f4aeaf7c49e1efe12981be1a63906843d580a067eb
3=3a074102140ef6f13efa2baf844fb7240d17da198bf06316fa116e1b74998335
4=05e5a1650f134c26d16b1a97a3551e671ed5bfec7160614efd5dce8ec9b9e782
..........
2736=002b7688604353951bb95090de38a0d08c700741ce1b5aa4c2faededda355a4a
CDHash=e7ce8c154244084fcf1856b471de764fbeaa0929
Signature size=8980
Authority=Developer ID Application: Trust1Team bvba (59YJFRZ48G)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=23 Dec 2024 at 13:59:09
Info.plist entries=14
TeamIdentifier=not set
Runtime Version=15.2.0
Sealed Resources version=2 rules=13 files=2
Nested=MacOS/test_binary
Internal requirements count=1 size=96 after searching the web a bit regarding this it indicated looking at issues during signing, As i did not get any errors at signing itself I continued looking and then stumbled on this post electron/osx-sign#131. This peaked my interest as we have some internal tools we also codesign and notarize where we updated the certificates our keychain to always be trusted for codesigning and timestamping as you can see in the screenshot below. It seemed odd that this could cause any issues, but it was worth a try. And yes for some reason this resolved the issue with notarization. For reference this is the command we use for one of our tools. I think the main difference here it that it selects a specific keychain database to use and serach for the certificate. This is the user's own keychain, while the certificate is also present in the codesign -f --timestamp --entitlements entitlements.plist --sign "Developer ID Application" --options runtime --keychain $HOME/Library/Keychains/login.keychain-db $BINARY_NAME Al tough the issue is resolved for me specifically I think it would be beneficial to know why this is occurring. And maybe add to the documentation this specific case under a FAQ section maybe? |
Describe the bug
We are in the process of distributing 2 different Tauri applications for multiple architecture, one is still on V1 while the other is V2. When building a release version for MacOS we're getting notarization errors the moment we add 1 or more sidecar's via the
externalBin
property.Both the applications successfully build and notarized when the
externalBin
property is removed from the configuration.I've tested this also with a clean project and a clean binary (prints hello world) where I also followed the steps defined in
https://v2.tauri.app/develop/sidecar/ and https://v2.tauri.app/plugin/shell/
Reproduction
I've created a basic setup here https://github.com/GillesPlatteeuw/tauri-sidecar-test/tree/main
To reproduce the error i've created a tauri application with
The frontend framework does not really matter in this case
I've created the test binary via rust
cargo new test_binary
and created a release executable viacargo build --release
. I've copied over the binary to thebinaries
folder and renamed it with the correct target triple appended.I then followed the documentation to add a sidecar binary. https://v2.tauri.app/develop/sidecar/ and https://v2.tauri.app/plugin/shell/
Then make sure you've updated the
tauri.conf.json
with the MacOS specific configuration for signing and notarization, i've redacted our signing identity with *** in the example below ( tauri.conf.json > bundle > macOS)Finally you can run
yarn tauri build -- --verbose
to build, codesign, notarize and bundle.Expected behavior
Have a valid codesigned and notarized bundled application (DMG)
Full
tauri info
outputThe text was updated successfully, but these errors were encountered: