Putting a Contents directory, either in Versions/A or at the top level will make codesign barf, complaining about an invalid bundle format. An important thing to note is that framework bundles do not have a Contents directory. Despite the insistence that this was the way to do it, it flat out did not work. I was pointed to this article which suggests I put the program in Contents/Helpers.
It got through codesigning and notarization checks without issue and ran fine after that.īut it seems that the problem is more subtle than that as whatever code that clears quarantine flags on embedded bundles didn’t like that. The solution I came up with back then was to put any executables alongside the framework binary, which would be in Versions/A with a symbolic link at the top level of the framework bundle. Sparkle originally put Autoupdate in Resources which is incorrect and can cause subtle issues.
This all lead to an investigation into where should Autoupdate, or executable binaries in general, be put in a framework.
The Autoupdate helper runs when your app is terminated so that it can install and run the new version.
For those that don’t know, Sparkle is a very commonly used framework for apps to update themselves. The DTS engineer was able to reproduce the issue on a VM and dig up a log message indicating that it could not clear the quarantine flag on the Autoupdate helper app in the Sparkle framework. I ended up filing a DTS incident to get some feedback from Apple. I suspected there was something wrong with my bundle that was causing these issues. As a short term workaround, on first run, I had Hazel recursively remove its quarantine flag before it attempted to run the helper.Įven with the workarounds, something didn’t sit right with me. Note that unlike when a user launches an app from Finder where they will be asked to run the app, a login item helper will fail to launch without any prompt. When the user copies an app, like say from a disk image to /Applications, the quarantine flag should be cleared for the app and everything inside but for some reason it was not clearing it for the embedded binaries. Logs from users showed that the quarantine flag was still set on the helper and that was preventing it from being run. Possibly related to the above, there was also an issue with the embedded helper app not running. As a workaround, I ended up using the private SecTranslocate.h APIs to detect the translocation and compensate appropriately. It’s my understanding that if an app and its containing dmg is signed and notarized, it shouldn’t be translocated. Why was Hazel being translocated? I’m still not sure. Hazel is unaware of this and as a result, doesn’t run the installer. When translocated, the binary is no longer on the disk image, instead it is copied to a temp location on disk. If you don’t know what translocation is, I suggest reading this article: Further investigation turned up that Hazel was being translocated. For the installer to trigger, Hazel needs to detect that it is running from a disk image. Not sure how the binary got added to the Copy Files phase there but it was an easy fix to remove.Īnother issue was that the installer wasn’t triggering for some people. This worked fine when the binary was in the framework bundle but when it was at the top level of the main app bundle, it escaped the app bundle itself. The binary had an rpath which escaped the framework bundle as it depended on a sibling framework. Turns out, I had mistakenly added a binary to the top level bundle (it was originally in a framework). Strangely enough, that person didn’t receive the “Unidentified developer” error alert. I had various users send in logs, but it was only when someone found a log message pertaining to the rpath for one of the binaries in the bundle that I was able to identify the problem. The biggest problem at launch was some users getting an “Unidentified developer” alert when opening the dmg. In my release build process, I do a codesign -verify as well as spctl to make sure everything is hunky-dory before submitting to Apple for notarization. Now before I get into it, remember during all this that Hazel is codesigned and notarized with no warnings or errors. As mentioned in my last post, I had various issues with codesigning and notarization during Hazel 5’s launch.