Hamish’s research is very interesting. Thomas, I hope that you don’t mind, but I took a peek inside of your application.
I want to understand what App Wrapper doesn’t like about your application, specifically the Sparkle.framework. It claims that the executable is missing, so I need to double my code as it’s there and valid I might add.
The other thing that App Wrapper notices (which it can deal with) is PowerPC code. Several libraries include PowerPC and couple even have 64-Bit code. Last time I checked 10.9 + doesn’t sign PowerPC code and at one point rejected a binary with PowerPC code in it.
Here’s an example linked to path in the dylib “/PluginTemp/Plugins/NSCoder/libMBSNSCoder.gcc4.cocoaintel.debug.dylib”, the dylib is “/Frameworks/MBS Real Studio CocoaBase Plugin.rbx_12.dylib”.
Which is correct. Code Signed DMGs do not get translocation or quarantine (at least not from the tests shared above).
Following on, I ran FaF through the prototype AW4 checking process, these are some of the potential issues that it found.
#1 “DateControl.rbx_0.dylib” is linked against OS X 10.4 and may need updating. #2 All the MBS plugins link to libraries outside of safe locations. #3 ShortcutTranslationLibLeopard.dylib & ShortcutTranslationLibTiger.dylib are Mach-O executables and should be in an executable location not the resources folder (see the previously linked code signing technote). #4 SparkleCarbon.framework, CFBundleName doesn’t match the file name. While it still works it goes against the Framework guidelines. #5 Several libraries include Intel 64-Bit, while the main application is only 32-Bit.
Maybe one of these reasons is why FaF is really slow to launch.
Last from me this morning, I downloaded iFFMPEG from Christoph’s site and ran it through my prototype engine also and it appears that his application also has the plugins linking issue.
So Christoph & Thomas, if you can get a copy of the plugins from Christian which don’t link to wrong locations and try again.
[quote=279413:@Sam Rowlands]Last from me this morning, I downloaded iFFMPEG from Christoph’s site and ran it through my prototype engine also and it appears that his application also has the plugins linking issue.
So Christoph & Thomas, if you can get a copy of the plugins from Christian which don’t link to wrong locations and try again.[/quote]
I use the latest MBS plugins from Christian. I wasn’t aware of this.
Maybe Christian can chime in here?
@Marco Hof - your findings are exactly as we expect and explained here several times.
@Sam Rowlands - thanks for looking into the potential issues with my app.
I’ve sent an email to Christian so he looks into the pluging linking issue Sam points out.
BTW, Sam - you’ve not answered my question how AW signs the dylibs. Does it leave them alone or does it sign every executable with the user’s credentials, thereby replacing Xojo’s and MBS’s own signatures?
@Sam Rowlands , I’d be interested to know what happens if you run Light Blue (downloaded from the link above) through the AW4 checking process. It might help narrow down differences between Thomas’ and our app?
No worries… Trying to get to the bottom of this also.
Sorry, I didn’t see it earlier. App Wrapper signs everything that’s marked as executable, this includes dylibs, frameworks, Apple Scripts and so on. Working from the inside out.
I’ll take a look tomorrow for you (wrong computer at the moment).
BTW, I find it interesting that the all Plugin dylibs in apps built with Xojo 2016r1.1 do not have the executable flag set. According to your explanation, AW would then not sign those dylibs. Or how do you detect that a file is executable?
I wonder if there’s a cmdline tool that can fix those paths? Otherwise - Christian, maybe you just need to change the “current dir” into your temp dir before building.
Huge… Took my engine a whole 2 seconds to check the application
#1 Code signature is NOT time stamped (I think Time Stamping may be part of the cause of the slowdown anyway). #2 The same plugin issues as Thomas’s & Christoph’s apps.
The noticeable difference is the Time Stamp, I recall Thomas’ & Christoph’s app were Time Stamped. I wonder if you could try enabling “Time Stamping” in the Code Signing settings (the action icon next to the identity selector) and see if that makes any difference.
That was my initial reaction, it goes against Apple’s guidelines and both your application and Thomas’ used them. However after seeing that Hamish’s also has these issues and Hamish says he’s not experiencing any slow down.
The other difference I noticed is that his code signature is NOT time stamped. I strongly feel that this is the cause of the slow down. I’m imaging that when there’s a time stamp, it reevaluates to check something, probably connecting online to validate with Apple’s servers.
It could be worth testing, along with Hamish re-code signing using a Time Stamp.
Also, try testing the app start times with all networks disconnected. If that speeds things up, it would confirm that Apple tries to check online (which would be horrible, though).
In my very early tests I also had the impression Codesigning without timestamps was fixing the issue but because Joe told us not to do this and Xcode apps are always codesigned with timestamps I walked away from this theory.
1: Verify that everything I said yesterday during my tests still stands, because I’m now on another computer. Yes, it does: FAF is slow to verify and slow to start the first time but not subsequent times; Light Blue starts fast both first and subsequent times.
Re-sign the Light Blue app with timestamping on. You can download the test zip file from https://dl.dropboxusercontent.com/u/15108631/Light-Blue-Timestamped.zip . Download the zip file to the VM; unzip it; check that Light Blue is quarantined using RB App Checker Lite; run it. Light Blue is still fast.
Try turning off the network to the VM and re-running tests. Using a freshly unzipped copy of FAF, it is now very fast.
Try turning the network to the VM back on and re-running tests. Using a freshly unzipped copy of FAF is now slow.
[quote=279596:@Hamish Symington]3. Try turning off the network to the VM and re-running tests. Using a freshly unzipped copy of FAF, it is now very fast.
4. Try turning the network to the VM back on and re-running tests. Using a freshly unzipped copy of FAF is now slow.[/quote]
Yuck! Seems to substantiate my theory…
