[External] : Re: RFR: 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters

Wed Aug 23 23:14:02 UTC 2023

Hi Alan,

On Aug 22, 2023, at 7:40 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:

On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com<mailto:alexander.matveev at oracle.com>> wrote:

Hi Alan,

On Aug 22, 2023, at 3:35 PM, Alan Snyder <javalists at cbfiddle.com<mailto:javalists at cbfiddle.com>> wrote:

I’m confused by this.

The issue is marked as macOS, but on macOS you don’t need to “find” the certificate, codesign finds it using the text supplied by the user. jpackage does not need to understand this text.

This is done for error handling. If signing is requested jpackage tries to find the certificate to make sure it is exist and is not expired and will exit with error if it does not exist or expired. In case if we just pass user provided information to codesign, then jpackage will fail during signing and after app image was generated. jpackage will fail faster if user mistyped certificate name in case when jpackage checks for it first.

The problem with this solution is that it introduces bugs. This bug and JDK-8311877 both result from jpackage trying to perform its own certificate search instead of letting codesign do the search.

The claimed advantage of failing “faster" is negligible (it is a small difference and only happens when the user has made a mistake) and not worth the (proven) risk of introducing bugs.

If you think you can do a better job of diagnosing the failure to find a certificate than codesign, then you should post-process the failure of codesign. But I don’t see this as a worthwhile investment.

JDK-8308042 is about fixing bug in current approach used by jpackage. You suggestion is to passthrough value from “--mac-signing-key-user-name” to codesign and use it as value for "--sign” argument in codesign will change behavior of “--mac-signing-key-user-name” and I do not think that we should be doing this as part of this bug fix.

From documentation:
https://docs.oracle.com/en/java/javase/20/jpackage/support-application-features.html#GUID-8D9F0607-91F4-4070-8823-02FCAB12238D

If you want to distribute your application outside the Mac App Store, then you'll need the certificates "Developer ID Application: <user or team name>" and "Developer ID Installer: <user or team name>".

If you want to deploy your application through the Mac App Store, then you'll need the certificates "3rd Party Mac Developer Application: <user or team name>" and "3rd Party Mac Developer Installer: <user or team name>”.

If --mac-app-store is set we will look for "3rd Party Mac Developer Application: <user or team name>” and if we cannot find it we will fallback to "Developer ID Application: <user or team name>” and if it is not found we will fail. If --mac-app-store is not set we will look for "Developer ID Application: <user or team name>”. <user or team name> is value provided via “--mac-signing-key-user-name”.

I think you suggestion is to add additional argument to jpackage which will be used as passthrough value for "--sign” argument in codesign. I am still not sure if we should be doing this, but I am currently considering it as a solution for https://bugs.openjdk.org/browse/JDK-8311877 instead of adding "Apple Development” as fallback if we cannot find "Developer ID Application”.

Thanks,
Alexander

Second reason is that both jpackage and codesign will find certificate if it contains provided key name/identity. codesign will fail if it finds two or more certificates, but jpackage will use first one with warning message.

Surely codesign can handle certificates with unicode names, can’t it?

Yes it can, but problem was is that our certificate validation code was not able to handle certificates with Unicode names.

Exactly my point. By doing your own certificate validation you risk doing it wrong.

Thanks,
Alexander

On Aug 22, 2023, at 3:15 PM, Alexander Matveev <almatvee at openjdk.org<mailto:almatvee at openjdk.org>> wrote:

- Added support for certificates with UNICODE characters.
- Added new approach to find certificate using "security" and "openssl" commands. Just "security" does not works, since it can truncate certificates name. "security" is used to dump certificate in PEM format and then "openssl" to get subject form PEM.
- New approach works with UNICODE and ASCII, but I left old approach to avoid regressions. If old approach fails to find certificate (UNICODE or very long subject case) we will fallback to new approach.
- Added tests for UNICODE to SigningAppImageTest and SigningPackageTest.java. I do not think that we need to cover other signing cases for UNICODE.

-------------

Commit messages:
- 8308042: [macos] Developer ID Application Certificate not picked up by jpackage if it contains UNICODE characters

Changes: https://git.openjdk.org/jdk/pull/15394/files
Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15394&range=00
Issue: https://bugs.openjdk.org/browse/JDK-8308042
Stats: 444 lines in 11 files changed: 248 ins; 60 del; 136 mod
Patch: https://git.openjdk.org/jdk/pull/15394.diff
Fetch: git fetch https://git.openjdk.org/jdk.git pull/15394/head:pull/15394

PR: https://git.openjdk.org/jdk/pull/15394

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230823/20942884/attachment.htm>