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

[Alexander Matveev]

Hi Michael,

On Aug 22, 2023, at 11:33 PM, Michael Hall <mik3hall at gmail.com<mailto:mik3hall at gmail.com>> wrote:



On Aug 22, 2023, at 9: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.


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.


Assuming code sign will catch the errors discussed or even not.

Would it make sense to do post validation of the entire app after completion?

Good point, but I am not sure if we should be doing this.

Thanks,
Alexander


echo '*******************'
echo 'verifying signature'
echo '*******************'
codesign -v --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess install'
echo '********************'
#spctl --assess --type install --verbose=4 outputdir/HalfPipe.app
echo '********************'
echo 'spctl assess execute'
echo '********************'
#spctl --assess --type execute --verbose=4 outputdir/HalfPipe.app

I don’t remember why I killed the spctl checks. Maybe they were flagging errors that weren’t?



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