Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [orbit-dev] macOS Native libjnidispatch.jnilib in com.sun.jna_* jars not codesigned


Thanks for the quick response and pointing out the issue on the project (didn't know about that project). The full error log thrown to us by the Apple Notarization service is exactly the same as the one shown there.

[...] because the Orbit project does not build the natives
Really there is no need to (re)build the native libraries, it could be codesigned using the file present on the released jar. In fact it is what we ended up doing in our pipeline (using our Apple Developer certificate).
I'm not aware if there is already another bundle in Orbit that has a native library that is codesigned by the Eclipse project.

[...] the bug has a clue as to the problem with notarization, the version of macOS?
The version isn't really the problem as it is notarized on an Apple service. 
I think he mentioned it because from 10.14.5 it is required that the app is notarized as it is stated here:
Beginning in macOS 10.14.5, software signed with a new Developer ID certificate and all new or updated kernel extensions must be notarized to run. 
Beginning in macOS 10.15, all software built after June 1, 2019, and distributed with Developer ID must be notarized.

I've downloaded the following and it seems that it only has the 5.8 version which includes a lib for 2 different darwin/macos architectures (aarch64 and x86-64). The first one seems to have a codesign but I'm not totally sure that it is valid (there is no Authority tag and the TeamIdentifier tag is not set). The second one is not codesigned at all.
I still don't know why the notarization of the Eclipse is not throwing an error about it.

$ wget

$ spctl -a -vvv -t install accepted
source=Notarized Developer ID
origin=Developer ID Application: Eclipse Foundation, Inc. (JCDTMS22B4)

$ jar xf com.sun.jna_5.8.0.v20210406-1004.jar com/sun/jna/darwin-aarch64/libjnidispatch.jnilib com/sun/jna/darwin-x86-64/libjnidispatch.jnilib

$ codesign -vvv --display --deep --strict com/sun/jna/darwin-aarch64/libjnidispatch.jnilib
Format=Mach-O universal (arm64)
CodeDirectory v=20400 size=1366 flags=0x20002(adhoc,???) hashes=39+0 location=embedded
Hash type=sha256 size=32
CandidateCDHash sha256=0bbfc8b3d63d8668a4700838b2be6ae86ad03230
CandidateCDHashFull sha256=0bbfc8b3d63d8668a4700838b2be6ae86ad03230e927c6c0f7373bd9db98034f
Hash choices=sha256
Info.plist=not bound
TeamIdentifier=not set
Sealed Resources=none
Internal requirements=none

$ codesign -vvv --display --deep --strict com/sun/jna/darwin-x86-64/libjnidispatch.jnilib
com/sun/jna/darwin-x86-64/libjnidispatch.jnilib: code object is not signed at all

Let me know if I can make any other test if needed.


On Tue, Apr 13, 2021 at 8:53 PM Jonah Graham <jonah@xxxxxxxxxxxxxxxx> wrote:
Hi Martin,

Thank you for bringing this to our collective attention. As far as I know the Eclipse platform notarizes every build available from and I haven't heard of any recent notarization problems. I will be building and notarizing the EPP packages on Thursday so I will keep this in mind.

I don't have easy access to a macOS machine - can you see if the 4.20M1 bundle available from the above link has the same issue? If not, I suspect in someway the notarization is being run differently.

However, if this is a problem and the JNA needs to be signed for macOS then the problem probably needs to be resolved by the JNA project because the Orbit project does not build the natives. However, the project has recently made it clear that this won't happen - see (BTW the bug has a clue as to the problem with notarization, the version of macOS?)

PS With any luck the final 4.20 (2021-06) release will not have JNA 4.5 in it and instead will be upgraded to JNA 5.8. Already 5.8 is used in some places.


Jonah Graham
Kichwa Coders

On Tue, 13 Apr 2021 at 19:31, Martin D'Aloia <martindaloia@xxxxxxxxx> wrote:

We sent our product (based on Eclipse 4.18) to Apple Notarization service and it failed with the following errors for this native library: plugins/com.sun.jna_4.5.1.v20190425-1842.jar/com/sun/jna/darwin/libjnidispatch.jnilib

- The binary is not signed.
- The signature does not include a secure timestamp.

Shouldn't this dependency be codesigned in Orbit?
Should I open a bug?

What is odd is that Eclipse 4.19 seems to be notarized but verifying this lib on the shipped jar we could see that it is not codesigned. I have no other explanation than it is a recent requirement from Apple. If that is the case maybe the notarization of Eclipse 4.20 would face the same issue.

$ cat
name=Eclipse Platform

$ spctl -a -vvv -t install accepted
source=Notarized Developer ID
origin=Developer ID Application: Eclipse Foundation, Inc. (JCDTMS22B4)

$ jar xf com/sun/jna/darwin/libjnidispatch.jnilib

$ codesign -vvv --display --deep --strict com/sun/jna/darwin/libjnidispatch.jnilib
com/sun/jna/darwin/libjnidispatch.jnilib: code object is not signed at all

If needed I can provide expected output and full error json provided by the Apple Notarization service.

Thanks in advance,
orbit-dev mailing list
To unsubscribe from this list, visit
orbit-dev mailing list
To unsubscribe from this list, visit

Back to the top