Bug 4369 - Provide signed OS X client
Summary: Provide signed OS X client
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Client platforms (show other bugs)
Target Milestone: 4.4.0
Assignee: Peter Åstrand
Keywords: hean01_tester, relnotes
Depends on: 5466
Blocks: 5469
  Show dependency treegraph
Reported: 2012-08-07 14:48 CEST by Peter Åstrand
Modified: 2015-04-17 13:53 CEST (History)
1 user (show)

See Also:
Acceptance Criteria:


Description Peter Åstrand cendio 2012-08-07 14:48:27 CEST
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:

Comment 1 Peter Åstrand cendio 2012-08-13 11:57:29 CEST
Apparently, the Mac App Store does not allow GPL applications. See http://en.wikipedia.org/wiki/Mac_App_Store.
Comment 2 Peter Åstrand cendio 2015-03-04 10:34:46 CET
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:

Some links:

There's also a tool called "ldid" what seems to be more or less a codesign replacement:

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

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

Verified signed / unsigned differences with gatekeeper enabled.

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