Bug 4369 - Provide signed OS X client
: Provide signed OS X client
: ThinLinc
Client platforms
: 3.4.0
: PC Unknown
: P2 Normal
: 4.4.0
Assigned To:
: 5466
: 5469
  Show dependency treegraph
Reported: 2012-08-07 14:48 by
Modified: 2015-04-17 13:53 (History)
Acceptance Criteria:



You need to log in before you can comment on or make changes to this bug.

Description From cendio 2012-08-07 14:48:27
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:

------- Comment #1 From cendio 2012-08-13 11:57:29 -------
Apparently, the Mac App Store does not allow GPL applications. See
------- Comment #2 From cendio 2015-03-04 10:34:46 -------
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:

Some links:

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:
------- Comment #4 From cendio 2015-03-05 09:35:31 -------
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:


Also interesting:


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
------- Comment #6 From cendio 2015-03-12 15:32:31 -------
(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.
------- Comment #7 From cendio 2015-03-12 15:51:07 -------
The task of finding a signing solution that works on Linux has been moved to
bug 5469.
------- Comment #8 From cendio 2015-03-19 11:21:32 -------
A new OS X machine is up and running. Tweaked script and documentation in
r30168. Closing.
------- Comment #9 From cendio 2015-04-15 15:33:57 -------
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
------- Comment #10 From cendio 2015-04-16 11:02:05 -------
(In reply to comment #9)
>   - copy-sign-bundles strips buildnumber when rebuilding client zip
>     bundle.

Fixed in commit r30245
------- Comment #12 From cendio 2015-04-16 15:17:01 -------
(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
------- Comment #13 From cendio 2015-04-17 13:51:29 -------
Looks good now.

Verified signed / unsigned differences with gatekeeper enabled.