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 <javali...@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.
