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.
Surely codesign can handle certificates with unicode names, can’t it? > 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 >
