jpackage code signing identity

[Alan Snyder]

I would still like to hear from someone on the jpackage team about this issue...

> On Jun 25, 2023, at 8:21 AM, Alan Snyder <javalists at cbfiddle.com> wrote:
> 
> I’m having trouble using the code signing feature of jpackage for macOS.
> 
> The problem appears to be here:
> 
> result = MacBaseInstallerBundler.findKey(
>                             "Developer ID Application: ", user, keychain);
>                     }
> 
>      boolean useAsIs = teamName.startsWith(keyPrefix)
>                 || teamName.startsWith("Developer ID")
>                 || teamName.startsWith("3rd Party Mac");
> 
>         String key = (useAsIs) ? teamName : (keyPrefix + teamName);
> 
> 
> 
> My certificate has a different prefix “Apple Development: ” in the keychain.
> I don’t think I made this up, so I don’t think I should try to change it.
> 
> Why is jpackage being so restrictive in its lookup of the signing key?
> Why doesn’t it just pass the string to codesign, which has its own rules for interpreting signing identities (see below)?
> 
> I typically use the 10 character alphanumeric key that is part of the name when I use codesign directly.
> 
> The identity is first considered as the full name of a keychain identity preference. If such a preference exists, it directly names the identity used. Otherwise, the identity is located by searching all keychains for a certificate whose subject common name (only) contains the identity string given. If there are multiple matches, the operation fails and no signing is performed; however, an exact match is preferred over a partial match. These comparisons are case sensitive. Multiple instances of the exactly same certificate in multiple keychains are tolerated as harmless.
> If identity consists of exactly forty hexadecimal digits, it is instead interpreted as the SHA-1 hash of the certificate part of the desired identity. In this case, the identity's subject name is not considered.

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