[External] : Re: [jpackage] JDK25 no longer takes into account --mac-package-identifier
Alexey Semenyuk
alexey.semenyuk at oracle.com
Thu Nov 6 20:57:46 UTC 2025
Daniel,
I filed [1] CR to track the work on fixing the breaking change in jpackage.
I'm on the fence about how to fix it, though.
Restoring the old behavior imposes security risk.
Making jpackage fail if the "--mac-sign" option is specified without
options specifying signing identity makes it redundant.
If you have a preference, please share.
In situations when it is ambiguous which certificate to pick jpackage
will pick the first one and issues a warning. E.g.:
---
WARNING: Multiple certificates found matching [Developer ID Application:
jpackage.openjdk.java.net] using keychain
[jpackagerTest-duplicate.keychain], using first one
---
I agree with your suggestion that jpackage should exit with an error in
this situation instead of issuing a warning. I filed [2] to track this
change.
[1] https://bugs.openjdk.org/browse/JDK-8371438
[2] https://bugs.openjdk.org/browse/JDK-8371440
- Alexey
On 11/6/2025 5:51 AM, Daniel Peintner wrote:
> Alexey, all,
>
> Thank you very much for your help.
> I still have issues making it to work, and I shared logs privately.
>
> Anyhow, some general comments/suggestions.
>
> You are right, with JDK21 it was enough to state "--mac-sign"option,
> and it picked the (only/correct) certificate (in my case).
>
> As I understand, with JDK25 this is no longer the case. I don't want
> to argue whether the *old* or *new* way is preferred. However, it is a
> breaking change.
> Hence, what I may suggest, though, is that it throw errors if the
> expected information (i.e., "--mac-signing-key-user-name") is missing.
> Otherwise, a developer doesn't know that there is a problem.
>
> The same goes to situations when it is not unique which certificate to
> pick. You pointed me to [1] which fixes the problem that I can find
> the certificate with *partial* information without the need to specify
> the full --mac-signing-key-user-name.
> In situations where there are more matches, I would argue the process
> should fail again with an error message hinting the problem (e.g.,
> certificate not uniquely identifiable). Looking at [2] I don't think
> this is the case.
>
> Thank you very much for your continuous support!
>
> -- Daniel
>
> [1] https://bugs.openjdk.org/browse/JDK-8371094
> [2]
> https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/0555f6228c59c6739b8b824d64eb6c1545a5520a__;!!ACWV5N9M2RV99hQ!J9oKLyj9n-_FtPD_BoRVwSb7xOZS7pc5TH8lXgkpNrCsgfImgZSBnSHzMCb5uslFMX6y38jJLJpUjkaIrEAJOrozjxjNy2Y$>
>
>
>
> On Wed, Nov 5, 2025 at 7:31 PM Alexey Semenyuk
> <alexey.semenyuk at oracle.com> wrote:
>
> Daniel,
>
> I've commented on the logs you shared privately. Adding some
> thoughts to the mail list.
>
> jpackage configuration at [1] is missing
> "--mac-signing-key-user-name" or "--mac-app-image-sign-identity"
> option. I noted it the private email as well.
> At first I assumed it was a mistake, but then I came across an old
> thread about the very same jpackage issue at [2] where you state
> that "--mac-sign" option is sufficient to make jpackage find the
> signing identity. So this is intentional.
>
> jdk25 jpackage will not look up for the signing identity unless
> "--mac-signing-key-user-name" or "--mac-app-image-sign-identity"
> option is specified. I'm surprised it did in older releases.
>
> For the sake of backward compatibility we can restore this
> behavior. But I think jpackage should exit with an error if the
> "--mac-sign" option is specified, but neither
> "--mac-signing-key-user-name" nor "--mac-app-image-sign-identity"
> is. The old behavior, when without these options jpackage picked
> the first available certificate with the common name starting with
> "Developer ID Application: " substring is not secure. It literally
> tells jpackage to pick any certificate without any filtering. If
> there is only one such certificate installed and it gets replaced,
> you will not even notice that your app is signed with a different
> certificate.
>
> I suggest you add "--mac-signing-key-user-name" or
> "--mac-app-image-sign-identity" option to jpackage command line at
> [1] to make it work.
>
> [1]
> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!J9oKLyj9n-_FtPD_BoRVwSb7xOZS7pc5TH8lXgkpNrCsgfImgZSBnSHzMCb5uslFMX6y38jJLJpUjkaIrEAJOrozs2mvjF8$>
> [2]
> https://mail.openjdk.org/pipermail/core-libs-dev/2021-August/080291.html
>
> - Alexey
>
> On 11/5/2025 4:16 AM, Daniel Peintner wrote:
>> Hi Alexey,
>>
>> Thank you for your reply.
>>
>> Does the warning message resembles the one at [1]?
>>
>>
>> Yes, exactly.
>>
>> I think your evaluation that the step 1 failed is correct.
>> I'd suggest adding "--verbose" option to the step 1 command
>> line to get more details.
>>
>>
>> I updated a demo/test project to demonstrate the problem. You can
>> now also try it yourself.
>> https://github.com/danielpeintner/Java11Test/tree/non-modular
>> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/tree/non-modular__;!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMJdEvoaQ$>
>>
>> There you can also find the 3 jpackage commands I use
>> https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle#L148-L151
>> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/blob/fdefe61e7e99747d6a62ac4b0a778fb0151b22e4/build.gradle*L148-L151__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMSE1bEoY$>
>>
>> W.r.t. sharing the logs file. I will send them to you
>> *privately*. I quickly scanned them and I would rather not have
>> them on the reflector.
>>
>> The weird thing is, that the difference seems to happen in step
>> 1. Anyhow, running these commands the difference is also somehow
>> in step 2 where
>> * JDK21 makes popping up a dialog which asks me whether I want to
>> allow access to my keys
>> * JDK25 does not need any interaction
>>
>> I hope this helps to find the "difference".
>>
>> Thanks,
>>
>> -- Daniel
>>
>>
>>
>>
>> [1]
>> https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties#L85
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/4c6af03f81e068a98b8f4628b96682a54f3946da/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/MacResources_de.properties*L85__;Iw!!ACWV5N9M2RV99hQ!K6rxxdg-Kc1tXxF2aG05XgBmFlQ6WrLwFdABc58RZ9tnrLuEhINot7FSZdRxXzo478rpGyBTtLQZjBrbwRl2YfJMd-s2VkQ$>
>>
>> - Alexey
>>
>> On 11/4/2025 12:32 PM, Daniel Peintner wrote:
>>> Hi Alexey, all,
>>>
>>> I nailed down the problem to the following, which seems to
>>> differ between JDK25 and JDK21.
>>> Maybe this helps to reproduce the issue.
>>>
>>> jpackage is called 3 times in my process
>>>
>>> 1. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>> --type app-image --input
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/install/myPROJECT/lib
>>> --main-jar myPROJECT-25.11.03.jar --main-class
>>> eu.my_company.myproject.Launcher --dest
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>> --name myPROJECT --app-version 25.11.03 --runtime-image
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jre
>>> --java-options
>>> --add-opens=javafx.base/com.sun.javafx.collections=ALL-UNNAMED
>>> --java-options
>>> --add-opens=javafx.base/com.sun.javafx.event=ALL-UNNAMED
>>> --java-options
>>> --add-opens=javafx.controls/com.sun.javafx.scene.control=ALL-UNNAMED
>>> --java-options
>>> --add-opens=javafx.controls/com.sun.javafx.scene.control.behavior=ALL-UNNAMED
>>> --java-options
>>> --add-opens=javafx.controls/javafx.scene.control.skin=ALL-UNNAMED
>>> --java-options
>>> --add-exports=java.management/javax.management=ALL-UNNAMED
>>> --java-options
>>> --add-opens=java.xml/com.sun.org.apache.xerces.internal.util=ALL-UNNAMED
>>> --java-options
>>> --add-opens=javafx.graphics/com.sun.glass.ui=ALL-UNNAMED
>>> --icon src/main/deploy/package/macosx/myPROJECT.icns
>>> --mac-package-identifier eu.my-company.myproject --mac-sign
>>>
>>> 2. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>> --type pkg --dest
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>> --name myPROJECT --app-version 25.11.03 --app-image
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>> --file-associations
>>> src/main/resources/associations.properties --app-version
>>> 25.11.03 --vendor "My Company" --copyright "My Company"
>>> --mac-sign
>>>
>>> 3. /Library/Java/JavaVirtualMachines/jdk-21.jdk/Contents/Home/bin/jpackage
>>> --type dmg --dest
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage
>>> --name myPROJECT --app-version 25.11.03 --app-image
>>> /Users/daniel/Documents/GitHub/myPROJECT/build/jpackage/myPROJECT.app
>>> --file-associations
>>> src/main/resources/associations.properties --app-version
>>> 25.11.03 --vendor "My Company" --copyright "My Company"
>>> --mac-sign
>>>
>>>
>>> First it creates the app-image and afterwards it creates pkg
>>> and dmg and signs it.
>>>
>>> As you can see in the 3 commands, it uses JDK21.
>>> Once I change "jdk-21.jdk" with "jdk-25.jdk" it warns after
>>> step 2 already with the following message in German
>>>
>>> Warnung: Nicht signiertes app-image wird zum Erstellen von
>>> signiertem pkg verwendet.
>>>
>>> It translates to something like: it tries to sign pkg and
>>> complains that the app-image is not signed.
>>> Hence, somehow step 1 failed already but does not show any
>>> error/warning.
>>>
>>> Please let me know whether the above helps to reproduce the
>>> issue.
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>> On Tue, Nov 4, 2025 at 4:01 PM Daniel Peintner
>>> <daniel.peintner at gmail.com> wrote:
>>>
>>> Hi Alexey,
>>>
>>> Thank you for your reply.
>>> I am using the badass runtime plugin which calls
>>> jpackage under the hood.
>>>
>>> While trying to create an example project, I noticed
>>> that there were some changes
>>> '--mac-package-identifier' needs to go into imageOptions
>>> and not installerOptions.
>>> see
>>> https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385
>>> <https://urldefense.com/v3/__https://github.com/danielpeintner/Java11Test/commit/742fce0d9e2995554829b6f199f22f0b22a5d385__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-K4xefEo$>
>>>
>>> That fixed the problem with jpackage. Anyhow, it still
>>> does not work with JDK25 and macOS signing.
>>> Using the JDK25 seems to need additional options
>>> (compared to JDK21).
>>>
>>> With JDK25 and --mac-sign the process no longer opens
>>> the KeyChain access and asks for the credentials. Hence,
>>> the image itself is no longer signed which matches with
>>> what I see on the debug console
>>> "non signed app-image used to sign dmg" ... freely
>>> translated into English since I see the German version only
>>>
>>> Therefore, apple's notary service says invalid with the
>>> logs like "The binary is not signed with a valid
>>> Developer ID certificate".
>>>
>>> Using the *same* gradle file, switching to JDK21 works
>>> without any issues again.
>>> I will try to investigate further.
>>>
>>> Thanks,
>>>
>>> -- Daniel
>>>
>>>
>>>
>>>
>>> On Mon, Nov 3, 2025 at 7:30 PM Alexey Semenyuk
>>> <alexey.semenyuk at oracle.com> wrote:
>>>
>>> Hi Daniel,
>>>
>>> I can not reproduce the issue you experience with
>>> jdk25.0.1:
>>>
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>> --input input --dest output --type app-image
>>> --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello --mac-package-identifier
>>> com.my-domain.project
>>> $ echo $?
>>> 0
>>> ---
>>>
>>> If I run the same command line without `
>>> --mac-package-identifier` option it fails as expected:
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>> --input input --dest output --type app-image
>>> --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello
>>> Bundler Mac Application Image skipped because of a
>>> configuration problem: invalid mac bundle identifier
>>> [com.my_domain.project].
>>> Advice to fix: specify identifier with
>>> "--mac-package-identifier".
>>> ---
>>>
>>> The same failure for `--mac-package-identifier
>>> com.my_domain.project` (with the underscore):
>>> ---
>>> $ ~/jdk-25.0.1.jdk/Contents/Home/bin/jpackage
>>> --input input --dest output --type app-image
>>> --main-jar hello.jar --main-class
>>> com.my_domain.project.Hello --mac-package-identifier
>>> com.my_domain.project
>>> Bundler Mac Application Image skipped because of a
>>> configuration problem: invalid mac bundle identifier
>>> [com.my_domain.project].
>>> Advice to fix: specify identifier with
>>> "--mac-package-identifier".
>>> ---
>>>
>>> Any chance you accidentally put the string with the
>>> underscore instead of the hyphen as a value of the
>>> `--mac-package-identifier` option on your command line?
>>>
>>> - Alexey
>>>
>>> On 11/3/2025 11:43 AM, Daniel Peintner wrote:
>>>> Hi,
>>>>
>>>> I am about to switch a JavaFX project from JDK21 to
>>>> JDK25 and I noticed a problem when running jpackage.
>>>>
>>>> My domain has a hyphen, like in www.my-domain.com
>>>> <https://urldefense.com/v3/__http://www.my-domain.com__;!!ACWV5N9M2RV99hQ!PyybrFqsPzI4Zo0L-pavG2mZkHToVTLkE6V8ezQdZYV20QXukxrjgODsksKVmoxUVoJW9hQTe2Z1vC1xwikUQGK-KS5-g-8$>
>>>> Hence, my Java package reads like this:
>>>> com.my_domain.project
>>>> Note: hyphen becomes underscore.
>>>>
>>>> Running vanilla jpackage in JDK21 complained with
>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>> due to the *invalid* underscore and suggests me to
>>>> use "--mac-package-identifier"
>>>>
>>>> Hence, I added --mac-package-identifier
>>>> com.my-domain.project (with the hyphen again)
>>>> All good so far.
>>>>
>>>> Running the same code with JDK25 with the above
>>>> settings shows the error message again
>>>> Invalid Mac-Bundle-ID [com.my_domain.project]
>>>>
>>>> I can add any argument to --mac-package-identifier
>>>> It seems it is simply not taken into account.
>>>>
>>>> I am using JDK 25.0.1
>>>>
>>>> Is this a known issue with JDK25 and jpackage?
>>>> Is there any other way to make jpackage work?
>>>>
>>>> Thanks,
>>>>
>>>> -- Daniel
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20251106/99f77e86/attachment-0001.htm>
More information about the core-libs-dev
mailing list