What are the future plans for dealing with OSX code signing?
I read [1] that "With the release of OS X 10.10 DP 5 and 10.9.5, Apple changed the code signing format, especially regarding these resource rules. [...] The main change is that now you cannot exclude resources from being signed. You used to be able to use a file called ResourceRules.plist inside of the signed bundle to specify files which should not be considered when checking if the seal of a bundle was broken. As of the version 2 code signing, this does not work anymore. All code and resources must be signed — no exceptions. "
My question arises from reviewing PharoTour chapter in UPBE [2], where downloading the zip and running the app produces the dreaded {youApp} is an application downloaded from the Internet. Are you sure you want to open it?" Sure any aspiring programmer should know their way around this, but still its not very inviting.
So if we can no longer store a writable Image under the Resources folder, what are the alternatives?
1. Deliver app with read-only Image under the Resources folder. The INI file can define the location of the writeable Image under ../{user}/Library/. When the VM starts, if the writable Image file does not exist, the VM transparently copies the read-only Image from resources to the writable location.
2. Use a launcher application like PharoLauncher.
3. For a "portable" app (e.g. on USB stick) push the app down one folder, so rather than putting the Win/Lin executables inside the OSX app, the top level folder contains folders Windows, Linux, Common, and the app.
cheers -ben
[1] https://www.objc.io/issues/17-security/inside-code-signing/ [2] https://ci.inria.fr/pharo-contribution/job/UpdatedPharoByExample/lastSuccess...