#Making the most out of hazel noodlesoft update

#Making the most out of hazel noodlesoft update

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.