JetBrains / compose-multiplatform

Compose Multiplatform, a modern UI framework for Kotlin that makes building performant and beautiful user interfaces easy and enjoyable.
https://jetbrains.com/lp/compose-multiplatform
Apache License 2.0
16.29k stars 1.18k forks source link

Desktop app for Mac crash when running packaged app #679

Closed odvratnozgodan closed 3 years ago

odvratnozgodan commented 3 years ago

I made simple Compose Desktop application but it keeps crashing during startup with the following error(gradle task packageDmg and then run *.app or gradle task runDistributable):

dlopen(/Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib) failed. 

Error: dlopen(/Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib, 1): 
no suitable image found.  

Did find:
/Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib: 

code signature in 
(/Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib) 
not valid for use in process using Library Validation: mapping process and mapped file (non-platform) have different Team IDs

I have setup the signing and notorization process for the app and the notorization process finishes successfully. Also, I have checked the the *.app and the libjli.dylib inside the app with codesign and they are signed.

I have tried with packaging the app with JDK-15.0.1, 16.0.1-open(Java.net) and 16.0.1.j9(AdoptOpenJDK) but the result is the same.

I am using: • Compose version 0.4.0-build185("org.jetbrains.compose") • Kotlin 1.4.32

olonho commented 3 years ago

Please provide output of

codesign -dv  --verbose=4 /Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib

and compare that with output of same command for /Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/MacOS/*. Likely somehow JVM and library got signed by different entities.

odvratnozgodan commented 3 years ago

Here is the output for the first command:

Executable=/Users/brunoblazinc/Documents/Development/_PrivateDevelopment/DungeonDraw/desktopApp/build/compose/binaries/main/app/DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib
Identifier=libjli
Format=Mach-O thin (x86_64)
CodeDirectory v=20500 size=786 flags=0x10000(runtime) hashes=16+5 location=embedded
VersionPlatform=1
VersionMin=657664
VersionSDK=658944
Hash type=sha256 size=32
CandidateCDHash sha1=650f725df498a016a05f7d7e0189c3d4dc8bdecf
CandidateCDHashFull sha1=650f725df498a016a05f7d7e0189c3d4dc8bdecf
CandidateCDHash sha256=a5e984e8660c763178b1ad120c7dca0d1c215c53
CandidateCDHashFull sha256=a5e984e8660c763178b1ad120c7dca0d1c215c530cb67c6ee5a60dcea8c81ba4
Hash choices=sha1,sha256
CMSDigest=806ca9f5bb8e33d9e6f8d1cd2d939f1dffd106db34dc3e807f3bc22a6ecb1775
CMSDigestType=2
Page size=4096
CDHash=a5e984e8660c763178b1ad120c7dca0d1c215c53
Signature size=9037
Authority=Developer ID Application: London Jamocha Community CIC (VDX7B37674)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=21 Apr 2021 at 19:12:58
Info.plist=not bound
TeamIdentifier=VDX7B37674
Runtime Version=10.14.0
Sealed Resources=none
Internal requirements count=1 size=168

The output of the second command is different. That returns that it was signed with my Developer ID Application, which seems correct. If you need the output of the second one just let me know. I didn't want to post it here as it contains information regarding my Developer and Team ID.

olonho commented 3 years ago

It means, that there's inconsistency between those two, both of them shall be signed by VDX7B37674. Please clean and rerun.

odvratnozgodan commented 3 years ago

I have tried cleaning the project and rerunning but the result was the same. I haven't done any signing actions after the packageDmg gradle task finished, so it seems odd to me that the signing is different. In the build.gradle.kts of the desktop module I have specified the signing and notorization fields with values of my team, so I guess that is what is causing the inconsistency.

I have tried settings sign.set(false) in the build.gradle.kts. I checked the with codesign and now both files were signed by VDX7B37674, but when I tried to notorize the app it fails and I get the following output:

{
  "logFormatVersion": 1,
  "jobId": "9378694d-e433-454d-a46e-799741198988",
  "status": "Invalid",
  "statusSummary": "Archive contains critical validation errors",
  "statusCode": 4000,
  "archiveFilename": "DungeonDraw-1.0.7.dmg",
  "uploadDate": "2021-05-21T07:03:38Z",
  "sha256": "aee16daddb902aacb482b0525d7bd5a166daba20135bb0c4881fd37aba08222f",
  "ticketContents": null,
  "issues": [
    {
      "severity": "error",
      "code": null,
      "path": "DungeonDraw-1.0.7.dmg/DungeonDraw.app/Contents/MacOS/DungeonDraw",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    },
    {
      "severity": "error",
      "code": null,
      "path": "DungeonDraw-1.0.7.dmg/DungeonDraw.app/Contents/runtime/Contents/MacOS/libjli.dylib",
      "message": "The signature of the binary is invalid.",
      "docUrl": null,
      "architecture": "x86_64"
    }
  ]
}

I have to mention that I'm not running the notarizeDmg, instead I am running the command from the terminal. The reason for this is that I have multiple certificate providers(https://github.com/JetBrains/compose-jb/issues/674).

Do you have any idea how I could resolve this issue?

odvratnozgodan commented 3 years ago

Ok, I think that I found out the cause of this. The issue is caused because these two files have different signatures:

DungeonDraw.app/Contents/runtime/Contents/Home/lib/libjli.dylib
DungeonDraw.app/Contents/runtime/Contents/MacOS/libjli.dylib

I have tried the following:

  1. Disabled signing for the macOS target - both files were signed by VDX7B37674 and the app can be started without any errors, the issue arrises if the app is sent for notorization to the Apple service. The error that is returned is the one from my previous post
  2. With signing for the macOS target enabled - the first file(located at Home/lib/libjli.dylib) is signed by VDX7B37674, but the second file(located at MacOS/libjli.dylib) is signed with Y8Z27FN9Z7(my certificate). The notorization process finishes successfully but when I try to run the app I get the error Library Validation: mapping process and mapped file (non-platform) have different Team IDs

After further investigation it looks to me that MacJarSignFileCopyingProcessor.kt(link) is copying and then resigning the native libs that are copied.

Is this normal behaviour and if yes why is there a discrepancy between the two files? Should I just manually resign the original file(located in build/compose/tmp/main/runtime/lib/libjli.dylib)?

AlexeyTsvetkov commented 3 years ago

@odvratnozgodan what have you specified as signing.identity DSL property (or compose.desktop.mac.signing.identity via gradle.properties)? I think it should be London Jamocha Community CIC in your case. Is it so?

odvratnozgodan commented 3 years ago

No, I have set the value to my teams identity as a DSL. I have tested again with the recommended identity and I get the following error:

Execution failed for task ':desktopApp:createDistributable'.
> Could not find certificate for 'London Jamocha Community CIC' in keychain []

Possible solution:
 - Declare repository providing the artifact, see the documentation at https://docs.gradle.org/current/userguide/declaring_repositories.html
okushnikov commented 4 months ago

Please check the following ticket on YouTrack for follow-ups to this issue. GitHub issues will be closed in the coming weeks.