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