Notarization issues with jdk8

Question

francescoesteco OP

Created Feb ’20

Replies 5

Boosts 0

Views 1.8k

Participants 4

Hi all,

i'm facing notarization issues while trying to notarize a dmg package.
We distribute the jdk inside the app, but unfortunately i am getting a lot of these error (all related to Java/JDK, which is the one we get and extract from the Oracle website)

{

"severity": "error",

"code": null,

"path": "package.dmg/myApp.app/Contents/Plugins/jdk1.8.jdk/Contents/Home/jre/bin/java",

"message": "The binary uses an SDK older than the 10.9 SDK.",

"docUrl": null,

"architecture": "x86_64"

},
Have I the possibility to solve this problem, or the Oracle developers should fix that?
Thanks in advance

Boost

Answer 1

Brigitte OP

Feb ’20

You have seen that?

https://bugs.openjdk.java.net/browse/JDK-8223671

You can only fix the problem with an old sdk by compiling the binary against a newer sdk.

I don't know if this is what you really want...

Greetings

Brigitte

0

Answer 2

francescoesteco OP

Feb ’20

This is the result i get with the following command
codesign -dv --verbose=4 java

Executable=Contents/Home/jre/bin/java

Identifier=net.java.openjdk.cmd

Format=Mach-O thin (x86_64)

CodeDirectory v=20200 size=584 flags=0x0(none) hashes=23+2 location=embedded

Library validation warning=OS X SDK version before 10.9 does not support Library Validation

VersionPlatform=1

VersionMin=657152

VersionSDK=657408

Hash type=sha1 size=20

CandidateCDHash sha1=bf12d6542ff2df3b6af01d0c38013fdbf1eb3ba5

CandidateCDHashFull sha1=bf12d6542ff2df3b6af01d0c38013fdbf1eb3ba5

Hash choices=sha1

CMSDigest=c37cad64703ae4ce6760fae8764a521ab1c8d17dd00b6f4956354128343a68ae

CMSDigestType=2

Page size=4096

CDHash=bf12d6542ff2df3b6af01d0c38013fdbf1eb3ba5

Signature size=8577

Authority=Developer ID Application: Oracle America, Inc. (VB5E2TV963)

Authority=Developer ID Certification Authority

Authority=Apple Root CA

Timestamp=29 Mar 2018 at 01:06:53

Info.plist entries=4

TeamIdentifier=VB5E2TV963

Sealed Resources=none

Internal requirements count=1 size=180

0

Answer 3

DTS Engineer OP

Apple

Feb ’20

The SDK used to build the code is not embedded in the code signature, but in the code itself. Try doing this:

% otool -l /path/to/one/of/your/libraries | grep -B 1 -A 3 LC_VERSION_MIN_MACOSX
Load command 8
      cmd LC_VERSION_MIN_MACOSX
  cmdsize 16
  version 10.7
      sdk 10.8

If the

sdk

field is less than 10.9, you won’t be able to notarise that code.

Share and Enjoy
—
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

0

Answer 4

TheUsual OP

Oct ’20

There is also this and its linked app. Of course, you will want to test to make sure your library actually runs properly on 10.9 and later.

0

Answer 5

DTS Engineer OP

Apple

Oct ’20

FYI, there have been some recent developments in this space. See Notarisation and the macOS 10.9 SDK for the details.

IMPORTANT Pay attention to this quote:

The first thing to do is come up with a medium-term plan for breaking
your dependency on libDodo.dylib. Relying on an unmaintained library
is not something that’s sustainable in the long term.

Modern, supported JDKs don’t have this problem. If you find yourself in this situation you should make a plan to update.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@apple.com"

0