[CMake] OSX Code Signing best practice

Eric Wing ewmailing at gmail.com
Fri Jul 15 13:20:48 EDT 2016


On 7/12/16, Harry Mallon <Harry at codexdigital.com> wrote:
> Hello all,
>
> What is the current best practice for code signing OSX .apps and binaries? I
> am using:
>
> 1. MAC_OSX_BUNDLE for my .app targets.
> 2. unix style executables
> 3. dylibs
> 4. A prefpane (which I haven't got working yet) using something like the
> below:
>
>     add_library(prefpane MODULE
>         ${sourceFiles}
>     )
>
>     set_target_properties(codexprefpane PROPERTIES
>         BUNDLE YES
>         BUNDLE_EXTENSION prefPane
>         XCODE_ATTRIBUTE_WRAPPER_EXTENSION prefPane
>         MACOSX_BUNDLE_INFO_PLIST ${prefpane_plist_file}
>     )
>
> I am not using the CPackBundle generator so I cannot use the signing in
> that. I have tried:
>
> 1. Using set_target_properties( .... "XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY"
> "${SIGN_ID}")
> 2. Using an add_custom_command step. This code signs before all the
> Resources are copied in so the signatures are invalid
>
> Any ideas?
> Harry
>

I do something similar. I also don't use CPack and need the build
process to respect normal Xcode run/debug/profile workflows where the
app bundle is built correctly on build and not through separate CMake
target steps.

I have a add_custom_command as a POST_BUILD to copy and sign my
frameworks, dylibs, and plugins. Then I use
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY to get Xcode to sign the rest of
the bundle through the normal Xcode mechanisms.

It works. I do find having to set the
XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY annoying. I kind of wish the CMake
generator could ignore that field and leave it to whatever the user
ends up setting (and not overwrite on every update regeneration)
because there are different identities you need depending on the
situation and changing this all the time in CMake scripts is annoying.
And I wish Xcode itself would automatically recursively sign
dependencies so I don't need to copy and sign manually.

-Eric


More information about the CMake mailing list