Re: [CMake] OSX Code Signing best practice

2016-07-15 Thread Eric Wing 
On 7/12/16, Harry Mallon  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
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

Re: [CMake] OSX Code Signing best practice

2016-07-14 Thread Roman Wüger 
Is it possible to sign after your package is complete (copying resource files 
and so on)?

I call a *.sh which is created from the CMake configure step which do the job.

Best Regards
Roman

> Am 12.07.2016 um 18:49 schrieb Harry Mallon :
> 
> 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
> 
> Harry Mallon
> CODEX | Software Engineer
> 60 Poland Street | London | England | W1F 7NT
> E ha...@codexdigital.com | T +44 203 7000 989
> -- 
> 
> Powered by www.kitware.com
> 
> Please keep messages on-topic and check the CMake FAQ at: 
> http://www.cmake.org/Wiki/CMake_FAQ
> 
> Kitware offers various services to support the CMake community. For more 
> information on each offering, please visit:
> 
> CMake Support: http://cmake.org/cmake/help/support.html
> CMake Consulting: http://cmake.org/cmake/help/consulting.html
> CMake Training Courses: http://cmake.org/cmake/help/training.html
> 
> Visit other Kitware open-source projects at 
> http://www.kitware.com/opensource/opensource.html
> 
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/cmake

-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake

[CMake] OSX Code Signing best practice

2016-07-12 Thread Harry Mallon 
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

Harry Mallon
CODEX | Software Engineer
60 Poland Street | London | England | W1F 7NT
E ha...@codexdigital.com | T +44 203 7000 989
-- 

Powered by www.kitware.com

Please keep messages on-topic and check the CMake FAQ at: 
http://www.cmake.org/Wiki/CMake_FAQ

Kitware offers various services to support the CMake community. For more 
information on each offering, please visit:

CMake Support: http://cmake.org/cmake/help/support.html
CMake Consulting: http://cmake.org/cmake/help/consulting.html
CMake Training Courses: http://cmake.org/cmake/help/training.html

Visit other Kitware open-source projects at 
http://www.kitware.com/opensource/opensource.html

Follow this link to subscribe/unsubscribe:
http://public.kitware.com/mailman/listinfo/cmake