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

[Alan Snyder]

> On Aug 22, 2023, at 4:42 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> Hi Alan,
> 
>> On Aug 22, 2023, at 3:35 PM, Alan Snyder <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.


> 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> 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
>>> 
>> 
>