Bugzilla – Bug 4369
Provide signed OS X client
Last modified: 2015-04-17 13:53:21
You need to
before you can comment on or make changes to this bug.
As described on
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:
Apparently, the Mac App Store does not allow GPL applications. See
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
Bad: It does not build on anything else than Mac OS X, and I cannot find a
It might be possible to port codesign to Linux/OpenSSL, though:
There's also a tool called "ldid" what seems to be more or less a codesign
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:
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:
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:
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
(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
A new OS X machine is up and running. Tweaked script and documentation in
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
(In reply to comment #9)
> - copy-sign-bundles strips buildnumber when rebuilding client zip
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.