https://kotlinlang.org logo
Title
s

spierce7

07/30/2021, 2:33 PM
I’m seeing errors when notarizing an application with files from compose. How would I work around that?
{
severity: "error",
code: null,
path: "My_App-1.0.0.dmg/My <http://App.app/Contents/app/sqlite-jdbc-3.34.1-371b212b7663f42133e45d49e82ad30.jar/org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib|App.app/Contents/app/sqlite-jdbc-3.34.1-371b212b7663f42133e45d49e82ad30.jar/org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib>",
message: "The binary is not signed.",
docUrl: null,
architecture: "x86_64"
},
{
severity: "error",
code: null,
path: "My_App-1.0.0.dmg/My <http://App.app/Contents/app/sqlite-jdbc-3.34.1-371b212b7663f42133e45d49e82ad30.jar/org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib|App.app/Contents/app/sqlite-jdbc-3.34.1-371b212b7663f42133e45d49e82ad30.jar/org/sqlite/native/Mac/x86_64/libsqlitejdbc.jnilib>",
message: "The signature does not include a secure timestamp.",
docUrl: null,
architecture: "x86_64"
}
Because of that I’m seeing
Status: invalid
   Status Code: 2
Status Message: Package Invalid
m

Michael Paus

07/30/2021, 3:52 PM
I recently had the same issue with a JavaFX application. My solution was to repackage the jar file. First I removed all native libraries which were not for the platform at hand (Mac in your case) and then I signed the native library and repacked everything back into the jar (without the removed libs of course). This also makes the package smaller because it does not contain the unneeded native libraries for all the other platforms anymore. You find the libs in the folder
/org/sqlite/native/
s

spierce7

07/30/2021, 4:38 PM
how do you sign the native library?
I ended up removing the library to get notarization to pass, but I still couldn’t open the desktop app
a

alexey.tsvetkov

07/30/2021, 5:19 PM
If the library is needed for the app to run, you can’t just remove the library. When macOS starts a new app for the first time, it sends Apple the hash/signature of the app to verify that this exact binary was notarized. If this exact binary was not notarized, the app would not start. Here’s the relevant issue from sqlite-jdbc https://github.com/xerial/sqlite-jdbc/issues/383 It seems that re-signing the library and packing it back into the jar should work. As a temporary workaround, you can do re-signing yourself (the easiest way to figure out the arguments for
codesign
is to run the build with
-Pcompose.desktop.verbose=true
and grep the log for
codesign
entries). Re-signing needs to be done before native distribution is published, so the easiest way would be to depend on manually signed library locally (or you can publish your signed jar to a private repo). Also it is probably possible to use Gradle artifact transformations for that. The proper solution would be for the JetBrains Compose Gradle plugin to sign jnilibs during packaging. We already do so for dylib files (I was not aware of jnilib format before today; seems like JDK itself does not use it since JDK 7 https://bugs.openjdk.java.net/browse/JDK-8127215).
m

Michael Paus

07/30/2021, 5:59 PM
As far as I know Compose uses JPackage to do the packaging which also does the signing of the jar files but this does not sign native libraries inside of jar files. They have to be signed by the originator or you have to do that manually yourself. This would also be difficult because Java does not have a clear concept of how to handle native libraries inside jars because in every case I have seen it was somehow handled differently. For the signing part itself I can’t help because I did not do that myself. A friend did that for me who has an Apple account.
s

spierce7

08/01/2021, 4:50 AM
I see - so I use codesign to sign the files, and I can use
-Pcompose.desktop.verbose=true
to get the arguments for the codesign command
The proper solution would be for the JetBrains Compose Gradle plugin to sign jnilibs during packaging.
This sounds like an easy change. Would there be any opposition to it? Why not just sign every file? Why even care about extensions?
It seems like this is all that’s necessary. Change https://github.com/JetBrains/compose-jb/blob/cab2ac642ed68206aa970a85f628453efb725[…]op/application/internal/files/MacJarSignFileCopyingProcessor.kt to
private val String.isDylibPath
    get() = endsWith(".dylib") || endsWith(".jnilib")
I created a PR for this here: https://github.com/JetBrains/compose-jb/pull/966
👍 2
m

Michael Paus

08/01/2021, 5:43 PM
Ah, that’s good to know. So they are not leaving the signing to jpackage as I originally thought. Probably for good reasons 😉
a

alexey.tsvetkov

08/02/2021, 12:10 AM
We sign dylibs in jars. Everything else is signed by jpackage. As for “why not just sign every file”. Well, it’s the first thing I tried, and a packaged app was not working.
s

spierce7

08/02/2021, 12:49 AM
Even after I removed sqlite to try and get the app runnning in a demoable state, it wouldn’t open after successfully notarizing
I have no idea how to debug the reason that it won’t open
m

Michael Paus

08/02/2021, 3:13 PM
@Scott Did you consult the Console app on your Mac?