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.
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 still don't know why the notarization of the Eclipse is not throwing an error about it.
$ spctl -a -vvv -t install Eclipse-4.20M1.app
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
$ 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.