Mavericks, Xojo & Code Signing

Okay, so with Mavericks Apple changed their code signing & code signature validation and this mainly affects Xojo, before it affects apps that include ‘nested’ code or basically additional executable code that is separated from the main executable file.

There are two issues, the first is easily solved.

#1 Executable code within the bundle, must be signed with the same code signature as the bundle.
In App Wrapper, go into the Preferences, then the “Advanced” section and then select “Force sign already signed components”.
In App Wrapper Mini (version 1.2), click on the action icon next to “Code Sign Application”, then make sure that “Code sign included plugins” & “Replace existing code signatures”.

This will work fine for apps that are distributed outside the Mac App Store.

#2 There is currently an issue with Apple’s security framework and App Store validation. For some users, not all, the store agent is unable to validate the signature of a Xojo application. I’m working with Apple to try to figure out the following.

Does this affect apps in testing or apps actually purchased from the App Store, some other developers claim it affects apps purchased as well as apps in testing.

Is there anything that I can do differently with App Wrapper to workaround this issue?

If there is nothing I can do, how long will it take for Apple to fix this issue.

The second issue is really scary, because it might mean that customers who are running Mavericks and purchase a Xojo made app through the App Store, may not be able to use it.

I will keep you all informed of what I discover. However I’m really disappointed that Apple has allowed Mavericks to ship with this issue.

All of my apps work flawless on the Final release of Mavericks. (except some animations which can be ignored)

Perhaps this may help :

http://furbo.org/2013/10/17/code-signing-and-mavericks/

This is probably not related, but…

During the Betas of 10.9, I discovered that code-sign validation had been tightened up, such that anychange to the Info.plist file after signing the app would break the signature. Then, I tested in the GM and this no longer happened. It seems as if Apple was playing around with the validation rules up until the last minute.

And so? What can we do to workaround?

[quote=42351:@Sergio Tamborini]Sergio Tamborini 1 hour ago Beta Testers, Xojo Pro
And so? What can we do to workaround?[/quote]

I will keep a boot disk under 10.8.5 until this charade is solved. Not in the mood to throw myself in hell to save the planet :stuck_out_tongue:

[quote=42274:@Michael Diehr]This is probably not related, but…

During the Betas of 10.9, I discovered that code-sign validation had been tightened up, such that anychange to the Info.plist file after signing the app would break the signature. Then, I tested in the GM and this no longer happened. It seems as if Apple was playing around with the validation rules up until the last minute.[/quote]
Technically any modification after code signing should invalidate the code signature of the bundle![quote=42351:@Sergio Tamborini]And so? What can we do to workaround?[/quote]
As of now, wait. Apple is aware of the issue, I’ve dealt with one Apple engineer who got me to test certain things to clarify what might be the cause.
I did ask for any possible workarounds and I know others have asked if it does affect customers purchasing from the Mac App Store (as we’re unable to test App Store builds before submission).
So far, we’re in day 3 and I’ve not actually received any complaints from people who can’t open apps that they’ve purchased from the App Store, so it may not be so bad, it’s just worrying that we can’t test App Store builds on Mavericks before submission.[quote=42211:@Pascal PLUCHON]Perhaps this may help :

http://furbo.org/2013/10/17/code-signing-and-mavericks/[/quote]
Thanks I did read this great article and was participating in the conversation that sparked the article, but I haven’t been able to make any use of Craig’s suggestions.

Anyway… I asked the problem to Ohanaware (App Wrapper developer) and they answered with this link… it’s the first step, but we still have to wait for Apple…

http://www.ohanaware.com/support/mavericksCodesign.php

That was me - I’m still awaiting further information from Apple at the moment. So far I’ve had no reports from people purchasing our apps from the MAS that they cannot use them…

We have a need to bug-fix in one of our app, but this morning we submitted the update to appstore correctly. Yes, we haven’t tested it, but I hope Apple will do for us.

Have some questions for Sam :

  • Does this problems occurred when signing on 10.8? on 10.9? Not related to the OS ? Or is this a problem only while downloading software from Mac App Store on Maverick, whatever the code sign OS was ?

  • I read from the The turbo.org post : “You’ll want to do a quick check of the build product before uploading it to either your website or iTunes Connect. The first thing you’ll want to do is check the signed bundle meets its designated requirement.”. I’ve check my program signed with App Wrapper and it’s seems ok (satisfies its Designated Requirement). Does this means that I can submit my app without problem for maverick users ?

  • Tried to check the pkg signature (with sudo installer -store -pkg Filmotech.pkg -target /- and got the message “Warning: Filmotech.pkg was signed with a certificate that is not valid for store submission.”. In App Wrapper the Mac App Store certificate is the Mac App Store and I’ve got all certificates in my keychains. What’s wrong ?

I don’t sell my software through the App store, and ran into a major problem this morning: I code-sign my app’s installer, .zip it, and then upload the .zip file to my web site, where users download it. When they download the .zip file in Mavericks and then un-zip it, OSX says it can’t open the installer because it’s from an unidentified developer. I tried signing the .zip file and the problem still happens.

I tried verifying the installer after it’s been un-zipped, and it is no longer code signed! Apparently Mavericks fails to restore code signing information when un-zipping.

How do I report this problem to Apple?

John, have you try to zip your file with another tool than the finder ?

I figured out there were actually two problems:

  • As Sam reported, Mavericks requires all of the components inside a bundle to be signed. Mine were not, so I used AppWrapper to do that.

  • Once that’s done, I move the application to an older Mac and run PackageMaker to build the installer. That works fine, and I then insert a plist entry into the installer bundle to include additional version information needed by school networks to tell when an update is needed. I then move the installer back to my Mavericks computer and code sign the installer. Prior to Mavericks, that worked fine. However, code signing under Mavericks chokes on the inserted plist entry, causing it to say the installer isn’t signed - never mind that PackageMaker isn’t signing the installer. So I skipped inserting the plist entry and now Mavericks is happy with the .zip file.

So the problem has been solved, albeit with a loss of functionality for those school networks…:frowning:

In theory, there’s a way to use “resource rules” to exclude your plist from the code-signing rules, but it’s not well documented.

See for example: http://www.cocoabuilder.com/archive/xcode/301731-resourcerules-plist-how-do-exclude-specific-files-from-codesigning.html

That looks like it could be really helpful - how on earth did you ever find that link?!?

I’m still puzzled because the installer was code signed after the plist entry was added - and not modified afterwards - so it shouldn’t be causing a problem.

In any case, I’ll check out your link and see if excluding the plist entry from code signing helps!

Thanks!

[quote=42475:@John McKernon]
I’m still puzzled because the installer was code signed after the plist entry was added - and not modified afterwards - so it shouldn’t be causing a problem.[/quote]

Signing it afterwards should be the right way to do it.

I think that the 10.9 issue is an actual bug on Apple’s end - but from reading discussions on the forums, nobody is quite sure what triggers it yet?

Nothing like bleeding edge technology…:wink:

Correct, but do Mac users have any choice? I just read a ZD-Net article that Apple is not planning on releasing any security fixes for older OS X versions, including Mountain Lion. Is that true?

Sure - don’t update first & ask questions later :stuck_out_tongue:

Apple’s made updating & upgrading so easy that every just does it regardless - then finds out AFTER that there are problems issues warts & bumps. I spent far too many years in a corporate workstation standards group (those IT guys that set the standard image for EVERY machine deployed in the company) that used Macs & Windows that I got VERY used to waiting on updates until many of the warts & bumps had been found, fixed & eventually I’d update.

Live & learn