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

Thu Aug 24 18:11:33 UTC 2023

Hi Alex,

Yes, I understand that this issue is about fixing a bug in the current approach.

Although it is a moot point, my opinion is that the current approach is ill-conceived and should be scrapped,
so improving it is a wasted effort.

The problems with the current approach:

1. An attempt is made to emulate the behavior of codesign for the purpose of predicting when it will fail.

The problem here is that if the emulation is not perfect, it can cause the packaging operation to abort needlessly.
This is basically a lost cause. You’ll never know when you have discovered the last bug.
In my opinion, the value of predicting when codesign will fail is very small, not even close to justifying
the risk of incorrectly aborting the packaging process.

If you are determined to try to predict when codesign will fail, it seems to me that a better approach is
to run codesign on a test file. But I still think it would be a mistake.

2. An attempt is made to enforce Apple’s policies and naming conventions.

There are two problems with this attempt. One is that Apple can change its policies and naming
conventions at any time, so you are signing up for maintaining consistency for an indefinite period of time,
and when they do make a change, there will necessarily be a delay before an updated jpackage
can be released.

The other problem is that you are assuming how the packaged application is going to be used.
As a developer using jpackage, I should be able to sign the application using any certificate that I choose.
I can see that you are trying to be helpful by finding the “right” certificate, but jpackage should not
block my ability to choose a specific certificate.

A bit of design philosophy: As far as I know, the issues faced by Java application developers regarding
the creation and selection of signing certificates are no different than the issues faced by other
Apple application developers. So it is not clear to me why jpackage should get involved in these
issues. Developers need to understand how to create and use certificates for applications distributed
using the two approaches recommended by Apple, and for that they need to read the Apple
documentation.

The focus of jpackage should be on JDK related issues. For code signing, that means identifying
the JDK files that need to be signed and the correct order of signing.

  Alan

> On Aug 23, 2023, at 4:14 PM, Alexander Matveev <alexander.matveev at oracle.com> wrote:
> 
> 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/20230824/eea5c8db/attachment.htm>