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...
On 26 Aug 2015, at 18:39, Ben Coman <btc@openinworld.com> wrote:
What are the future plans for dealing with OSX code signing?
We need to do it. We should have done it ages ago, nobody had the time.
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.
I want to ship the an app called âPharo5â that contains the VM, sources and a read-only image template. This just lives in /Applications. -> start it, it starts the template -> save template, it saves a one file pharo image -> klick on a pharo image, it starts the correct VM contained in Pharo<Version> package
2. Use a launcher application like PharoLauncher.
I would like to have the launcher concept be integrated with what i described. But I am not sure I want just a launcher to start when clicking on âPharoâ. And it needs to play well with people that manage images themselves.
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.
No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps). Marcus
On 28 Aug 2015, at 11:00, Marcus Denker <marcus.denker@inria.fr> wrote:
On 26 Aug 2015, at 18:39, Ben Coman <btc@openinworld.com> wrote:
What are the future plans for dealing with OSX code signing?
We need to do it. We should have done it ages ago, nobody had the time.
yes, it is in my infinite todo since a couple of years now :( maybe I will find the time when doing the spur transition⦠Esteban
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.
I want to ship the an app called âPharo5â that contains the VM, sources and a read-only image template.
This just lives in /Applications.
-> start it, it starts the template -> save template, it saves a one file pharo image -> klick on a pharo image, it starts the correct VM contained in Pharo<Version> package
2. Use a launcher application like PharoLauncher.
I would like to have the launcher concept be integrated with what i described. But I am not sure I want just a launcher to start when clicking on âPharoâ. And it needs to play well with people that manage images themselves.
We want PharoLauncher as the default download from some time now. Again⦠no time to polish the details⦠:(
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.
No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps).
+42 Esteban
Marcus
On 28-08-15 11:00, Marcus Denker wrote:
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.
No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps).
I strongly disagree. It is very useful to be able to carry a complete environment with me that is useable wherever I am. We will run into a lot less problems with it once we move to 64 bit. Stephan
On Fri, Aug 28, 2015 at 7:24 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 28-08-15 11:00, Marcus Denker wrote:
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.
No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps).
I strongly disagree. It is very useful to be able to carry a complete environment with me that is useable wherever I am. We will run into a lot less problems with it once we move to 64 bit.
Two cases benefit from a portable app: 1. In a corporate environment environment where systems are locked down preventing any software from being installed, PortableApps [1] are a lifesaver (even if in this case only portable across Windows machines). I use them *all* the time. Our IT support guys who are the only ones with permissions to install app are busy and I need tools as they arise, not in three days time. In our case, this is the difference between someone doing a taste-testing Pharo immediately when their interest is aroused, or not, because having to do forms and justify *why* they need it is too much friction, especially when the *why* is "I only want to *play* with it for a couple of hours, when I should be doing something else". It adds one small barrier [1] to adoption by a large market of potential *paying* customers. Actually PBE & UPBE describe how Pharo doesn't need to install into system areas - and I think that is beneficial to keep. An alternative could that the Pharo installer gives the option to install into either System or User area, much like Google Chrome does.. http://googlesystem.blogspot.com.au/2013/10/chromes-system-level-installer-n... 2. I think there was a lot of value in PBE having a portable zip to download locked to match the paper document. UPBE installation instructions currently refers to http://pharo.org/download -- but that will shift over time to Pharo 5. As much as the intent would be for UPBE to track Pharo releases, the reality of limited resources is that updating might be delayed, so it would be good for the installation instructions to point to a consistent image. Alternatively, the current download page might be copied to http://pharo.org/pharo4-pbe and remain untouched when Pharo 5 is released. Then the documentation just refers to that location for download and installation instructions. [1] http://portableapps.com/ Actually we could get some additional exposure by slotting Pharo in there. I know I tend to browse these available apps to "try them" and I assume others would do the same. [2] http://www.joelonsoftware.com/articles/fog0000000052.html cheers -ben
On 29 Aug 2015, at 05:11, Ben Coman <btc@openinworld.com> wrote:
On Fri, Aug 28, 2015 at 7:24 PM, Stephan Eggermont <stephan@stack.nl> wrote:
On 28-08-15 11:00, Marcus Denker wrote:
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.
No, I would retire that concept. (I know some people love it, but I think it does not fit into days world where the OS installs Apps).
I strongly disagree. It is very useful to be able to carry a complete environment with me that is useable wherever I am. We will run into a lot less problems with it once we move to 64 bit.
Two cases benefit from a portable app:
People who want it can put work into it. I will not. I want installers for Windows, Mac and Linux, with the scheme that I described. Marcus
participants (4)
-
Ben Coman -
Esteban Lorenzano -
Marcus Denker -
Stephan Eggermont