Codesign command on macOS does not include Hardened Runtime, so can not pass notarization

[AstroPixelProcessor]

I'm submitting a…

• bug report
• [ x ] feature request
• other

Short description of the issue/suggestion:

Why does the code sign command in javapackager/packagers/ MacPackager.java not include the option

--options runtime

so the hardened runtime is enabled so it can pass notarizationof the app by Apple?

What is the expected behavior?

The created DMG/PKG should be able to pass Apple's notarization when submitted.

What is the current behavior?

The created DMG/PKG will not pass Apple's notarization.

Please tell us about your environment:

• JavaPackager version: 1.6.2
• OS version: macOS Big Sur 11.0.1
• JDK version: Temurin JDK 17
• Build tool:
  • [ x ] Maven
  • Gradle

[AstroPixelProcessor]

Maybe I should not have submitted this request if the hardened runtime can be set with the entitlements.plist file? I was not able to find that though and google searches led me to think that it needs to be done with the codesign command.

Thank you in advance!

[AstroPixelProcessor]

Hi @fvarrui , I pulled the issue-161 branch and tried to use it in my project by installing it in my local maven repository with gradlew publishToMavenLocal

It fails in my project with a dependency for launch4j:

[ERROR] Failed to execute goal io.github.fvarrui:javapackager:1.6.4-SNAPSHOT:package (default) on project astropixelprocessor: Execution default of goal io.github.fvarrui:javapackager:1.6.4-SNAPSHOT:package failed: Plugin io.github.fvarrui:javapackager:1.6.4-SNAPSHOT or one of its dependencies could not be resolved: edu.sc.seis.launch4j:launch4j:jar:2.5.1 was not found in https://repo.maven.apache.org/maven2 during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of central has elapsed or updates are forced -> [Help 1]

https://repo.maven.apache.org/maven2 does not have this version of launch4j and the created pom for my local repo only shows it as dependency without repository configuration.

edu.sc.seis.launch4j launch4j 2.5.1 runtime

the correct repository is not configured in the pom for 1.6.4-SNAPSHOT, so it is not found.

oss-jfrog.org oss-jfrog.org https://oss.jfrog.org/artifactory/oss-snapshot-local/

or

gradle maven plugins gradle maven plugins https://plugins.gradle.org/m2/

Can that be configured in javapackageger or should I make changed in my own environment to make this work. I tried adding these repositories to my project, but that does not seem to solve it.

Thanks in advance,
Mabula

[fvarrui]

Hi @AstroPixelProcessor!
Yes, you are right, it's fixed in devel branch. I know you saw the related commit, but I haven't told you anything yet because I was testing. Sorry!

[AstroPixelProcessor]

Oh excellent, thanks again !

[fvarrui]

One question: Do you know what happens if I use codesign with --options runtime on an older Mac? Is it bypassed or it fails?

I was thinking to include notarization as part of the building process, but I can't test it.

[AstroPixelProcessor]

Hi @fvarrui,

I just tested the devel branch, but there is a minor problem with your implementation, this is executed now:

... codesign --force "--options ,[runtime]" --deep ...

so that will not work because it needs to be

... codesing --force --options runtime --deep ...

I will test the --options runtime command on my old mac with macOS 10.12.6 to see if it errors it or ignores it. I read that it will ignore it, but will test it now and will let you know in a couple of minutes.

[AstroPixelProcessor]

@fvarrui ,
Just tested

codesign --force --options runtime --deep ...

on my 10.12.6 macbook, that errors with

invalid argument runtime

so it does not ignore it.

If I do

codesign --force "--options runtime" --deep ...

it errors as well as

unrecognized option "--options runtime"

[AstroPixelProcessor]

It woud be easiest to remove those flags to be added to --options I think and just simply add this as a whole to the codesign args:

codesignArgs.add("--options runtime");

Then the command should work I would think.

[fvarrui]

Yes, thanks! I'll do so, but as I saw that there are more flags, I tried to support all of them ... Thinking in the future 😅

[fvarrui]

In any case, maybe we have to split it this way:

codesignArgs.add("--options");
codesignArgs.add("runtime");

[AstroPixelProcessor]

Ah yes, that should be fine and gives the flexibility for addtional other options so that is preferred.

[fvarrui]

I think the changes published in branch issue-161 are now working as expected ... please, try it and give me some feedback!

Thanks!!!

[fvarrui]

... codesign --force "--options ,[runtime]" --deep ...

I don't know what I was thinking when I wrote the code that generated this! 😆