Latest Code signing changes

[Sam_Rowlands]

So it seems Apple are changing the code signing requirements once again. The only thing that I can see, is that it now appears to be a requirement to code sign your application with 10.9 or newer.

Apple are also making a deal about having code in the ‘Resources’ folder and resources in a code folder. So I would advise if you’ve got helper applications in the “Resources” folder to move it to a more appropriate location.

If I find anything different, I’ll report back here.

[ChristopheDV]

Does this mean we have to use the ‘Mavericks Code Sign Engine’ in AppWrapper?

[Sam_Rowlands]

You should be fine, by simply using a machine running 10.9 to code sign your applications.

[ChristopheDV]

@117512:@Sam Rowlands

So I would advise if you’ve got helper applications in the “Resources” folder to move it to a more appropriate location.

Where should we put such helper apps (such as unix binaries, …) ? MacOS folder?

[ChristopheDV]

Did a quick test with downloading an old app (code signed with 10.7) and it still works fine in 10.10 DP5 - strange, maybe the new codesigning requirements isn’t activated in DP5 yet.

[Sam_Rowlands]

Right, scanned through a bucket load of Apple docs to find the correct locations, some of them seem a bit conflicting and it also seems that doing a Google search or ADF search turns up people putting files all over the place!

So the closest thing I could find is the Bundle Programming guide

Where it states:
MacOS

(Required) Contains the application’s standalone executable code. Typically, this directory contains only one binary file with your application’s main entry point and statically linked code. However, you may put other standalone executables (such as command-line tools) in this directory as well.

Frameworks

Contains any private shared libraries and frameworks used by the executable. The frameworks in this directory are revision-locked to the application and cannot be superseded by any other, even newer, versions that may be available to the operating system. In other words, the frameworks included in this directory take precedence over any other similarly named frameworks found in other parts of the operating system.

Plugins

Contains loadable bundles that extend the basic features of your application. You use this directory to include code modules that must be loaded into your application’s process space in order to be used. You would not use this directory to store standalone executables.

So in summary, it seems like unix executables should go in the “MacOS” folder.

However I’ve also seen specific XPC folders for XPC apps and a folder called “Helpers” with unix executables and last but not least, I’ve even see a Library folder with unix executables in the “Application Support” folder… For the time being, I’d go with MacOS as that’s what the Bundle programming guide says.

[Michel_Bujardet]

@117512:@Sam Rowlands

Apple are also making a deal about having code in the ‘Resources’ folder and resources in a code folder. So I would advise if you’ve got helper applications in the “Resources” folder to move it to a more appropriate location.

I just submitted an app that launches on start with a helper, thanks to Valdemar de Sousa VDSC package. The helper is in /Library/LoginItem. Hopefully that will be allright.

[Michel_Bujardet]

@117529:@Christoph De Vocht

Did a quick test with downloading an old app (code signed with 10.7) and it still works fine in 10.10 DP5 - strange, maybe the new codesigning requirements isn’t activated in DP5 yet.

They will probably do the same thing as the quicktime hurdle : block new submissions at the Application Uploader gate.

[Sam_Rowlands]

@117541:@Michel Bujardet

I just submitted an app that launches on start with a helper, thanks to Valdemar de Sousa VDSC package. The helper is in /Library/LoginItem. Hopefully that will be all right.

Should be, considering this is the correct place for login items in a Sandboxed application.

[Michel_Bujardet]

@117543:@Sam Rowlands

Should be, considering this is the correct place for login items in a Sandboxed application.

Thanks Sam. Will keep my fingers crossed, then

[Albin_Kiland]

@117527:@Sam Rowlands

You should be fine, by simply using a machine running 10.9 to code sign your applications.

I’ve got two machines. One on 10.9 and one on 10.8. WHY did I happen to use the 10.8 machine while code signing…

[Tim_Jones]

BTW - currently, this is only in effect for 10.9.5 (which is only in dev beta). The change to 10.10 will likely occur in a later beta.

[Mike_D]

[quote=117530:@Sam Rowlands]
So in summary, it seems like unix executables should go in the “MacOS” folder.

However I’ve also seen specific XPC folders for XPC apps and a folder called “Helpers” with unix executables and last but not least, I’ve even see a Library folder with unix executables in the “Application Support” folder… For the time being, I’d go with MacOS as that’s what the Bundle programming guide says.[/quote]

My app has a complete second Xojo app inside that it uses as a helper app. I wonder where that should be located, officially?

[Michel_Bujardet]

@117512:@Sam Rowlands

So it seems Apple are changing the code signing requirements once again. The only thing that I can see, is that it now appears to be a requirement to code sign your application with 10.9 or newer.

I just received a message from Apple that says that with 10.9.5 apps signed with 10.8.5 and earlier will not be recognized.

@117676:@Tim Jones

currently, this is only in effect for 10.9.5 (which is only in dev beta)

? ? I am still at 10.9.4 and have received no seed update yet…

@117678:@Michael Diehr

My app has a complete second Xojo app inside that it uses as a helper app. I wonder where that should be located, officially?

Read Sam Rowlands post above which indicates a link to the documentation.

[Michel_Bujardet]

[quote=117680:@Michel Bujardet]Tim Jones currently, this is only in effect for 10.9.5 (which is only in dev beta)
? ? I am still at 10.9.4 and have received no seed update yet…[/quote]

Correction : App Store just offers me to update. Did not receive the usual mail from Apple about that release, though.

[John_McKernon]

@117529:@Christoph De Vocht

Did a quick test with downloading an old app (code signed with 10.7) and it still works fine in 10.10 DP5 - strange, maybe the new codesigning requirements isn’t activated in DP5 yet.

My old app (a universal build), code signed with 10.9.4, fails to run in DP5. I posted a new conversation about it because it applies to RS2011, my solution was to use the --deep option when signing.

[Tim_Jones]

@117693:@John McKernon

My old app (a universal build), code signed with 10.9.4, fails to run in DP5. I posted a new conversation about it because it applies to RS2011, my solution was to use the --deep option when signing.

I discovered that with the earlier 10.10 drops. In fact, I’ve been using --deep for some time now even for older OS X versions. We found this on some Java and Python apps, so I also applied it to my RS / Xojo builds.

[Joe_Ranieri]

I’d encourage everyone here to read over Apple’s updated ‘OS X Code Signing In Depth’ technote. It talks about the changes that are coming in 10.9.5/10.10 and also mentions the --deep option.

[ChristopheDV]

@117702:@Joe Ranieri

–deep option

Sam, correct me if I am wrong but AppWrapper already uses this option?

[ChristopheDV]

@Joe:
It would be nice if you could add a new Destination for copying files after the build. MacOS folder is not available in the dropdownmenu.