As described on http://www.macrumors.com/2012/02/16/os-x-mountain-lion-limits-apps-to-mac-app-store-signed-apps-by-default/ and also verified on our 10.8 mac mini, the default setting is to only allow apps from Mac App Store, or from identified developers. Thus, the TL client won't run in the default configuration. We could consider adding the client to the Mac App Store, but personally, I don't like that approach, and in any case, that's a separate bug. But we could consider signing our client. Here's some information: https://developer.apple.com/library/mac/#documentation/Security/Conceptual/CodeSigningGuide/Introduction/Introduction.html
Apparently, the Mac App Store does not allow GPL applications. See http://en.wikipedia.org/wiki/Mac_App_Store.
It would be nice if we could sign the OS X Client, just as we are doing with the Windows client. Some details about this: Good: A tool called codesign_allocate is included in odcctools. Bad: This tool is not enough; you will also need "codesign". Good: "codesign" is part of the open source package security_systemkeychain. Tarballs available from http://www.opensource.apple.com/tarballs/security_systemkeychain/ Bad: It does not build on anything else than Mac OS X, and I cannot find a port. It might be possible to port codesign to Linux/OpenSSL, though: https://groups.google.com/forum/#!topic/cocotron-dev/YMd4Kf-DDWw Some links: http://stackoverflow.com/questions/13204407/how-to-codesign-an-existing-mac-os-x-app-file-for-gatekeeper http://stackoverflow.com/questions/11736368/how-to-sign-a-mac-os-x-application-in-linux http://stackoverflow.com/questions/23559912/alternative-to-mac-os-x-codesign-for-signing-binaries-on-linux There's also a tool called "ldid" what seems to be more or less a codesign replacement: http://www.saurik.com/id/8 https://github.com/BGerard/SIC---Simple-iOS-Compiler https://code.google.com/p/ios-toolchain-based-on-clang-for-linux/source/browse/trunk/iphonesdk-utils/ldid/ldid.cpp However, all documentation talks about "bypassing code signatures", so it's unclear if this tool can be used to create *real* signatures. Another idea would possible be if the "osslsigncode" tool could be used/adapted for Mac OS X. I created a ticket for this: https://sourceforge.net/p/osslsigncode/feature-requests/8/
It was possible to include unsigned content earlier, but after the migration to "version 2 code signing", this is no longer allowed. Now, all content must be signed. I've found a very good page about code signing: http://www.objc.io/issue-17/inside-code-signing.html Also interesting: https://bugzilla.mozilla.org/show_bug.cgi?id=758188 https://people.mozilla.org/~stmichaud/Gatekeeper/MLGatekeeper.html One of the comments there hints that an unsigned app can still run if it has landed on disk without the com.apple.quarantine.xattr attribute (typically as a result of downloading it from a web browser), for example from an installer. Creating .pkg files in Linux seems possible with this tool: http://hogliux.github.io/bomutils/ http://hogliux.github.io/bomutils/tutorial.html However, I assume that you will still need to sign the entire installer, which must then include all code, thus this is not a possible workaround...
(In reply to comment #5) > But in any case, the easiest "solution" is probably to avoid having the nightly > build sign the binaries, and instead do this afterwards: We could unpack the > client bundle ZIP, copy the OS X client ISO to a real OS X >= 10.9 machine, do > the sign there, copy the new ISO back and then create an updated bundle ZIP. It > should be possible to create a script that automates this. This script could be > used before copying anything to our "archive". Implemented in 30131. Tested using our 10.10 lab machine. Before closing this bug, I'd like to setup a new permanent OS X machine in our computer hall. makerelease.txt should then be updated with the correct hostname. The tester can test by executing the command in makerelease but with a different target directory than the "archive", and then trying out the package on a OS X machine.
The task of finding a signing solution that works on Linux has been moved to bug 5469.
A new OS X machine is up and running. Tweaked script and documentation in r30168. Closing.
Reopening due to following issues: - I don't have any password for the key chain which is asked by the script. - copy-sign-bundles script uses the mkisofs binary of local system which could create different outputs depending of versions / bugs. Shouldn't we use mkisofs of the build environment ? - copy-sign-bundles does not specify -input-charset CHARSET arg to mkisofs used for file name conversation, the fallback is to detect from system locale settings (utf-8 in my case). - copy-sign-bundles strips buildnumber when rebuilding client zip bundle.
(In reply to comment #9) > > - copy-sign-bundles strips buildnumber when rebuilding client zip > bundle. Fixed in commit r30245
(In reply to comment #9) > - copy-sign-bundles script uses the mkisofs binary of local system > which could create different outputs depending of versions / bugs. > Shouldn't we use mkisofs of the build environment ? > Fixed in commit r30248
Looks good now. Verified signed / unsigned differences with gatekeeper enabled.
