OSX code signing

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/lastSuccessfulBuild/artifact/PharoTour/PharoTour.html

> On 26 Aug 2015, at 18:39, Ben Coman <[hidden email]> 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 <[hidden email]> wrote:
>
>
>> On 26 Aug 2015, at 18:39, Ben Coman <[hidden email]> 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

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 <[hidden email]> wrote:
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-now.html


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

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