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"
}

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/

how do you sign the native library?

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).

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.

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

Ah, that’s good to know. So they are not leaving the signing to jpackage as I originally thought. Probably for good reasons 😉

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.

Even after I removed sqlite to try and get the app runnning in a demoable state, it wouldn’t open after successfully notarizing

@Scott Did you consult the Console app on your Mac?