OSX Installer

[Bastiaan Olij]

Hey Kelly,

That is very true and will mean a major restructure for Omnis in the way
they build the app bundle.

That said, this text still gives me reasons to believe that what I said
before holds true. You can code sign any document (its just hash stored
against the file to detect if the file has changed afterwards). Even
with data in the Contents/MacOS structure those files can be code signed
if you tell the code sign tool to include everything within that path.

The validity of the bundle will remain *as long as* there are no changes
to these files. The assumption is that data files do change. Case in
point, the serial.txt that may get a serial number written into it at
some point in time. However as those files can be made part of the
firstruninstall folder structure the files within the app will not
change. Just the copies in the users home folder. Nothing in code
signing should prevent the files from being copied into the users home
folder.

The contents of the firstruninstall folder itself doesn't change, and if
the contents is code signed, that would still result in a valid app bundle.

In theory...

Cheers,

Bas


On 20/08/14 2:48 PM, Kelly Burgess wrote:
> Hi Bas,
>
> I think what Bo is referring to is the change in v2 code signing where it requires every bit of code to be signed, and then you ask, what constitutes a bit of code, and that document
>
>   https://developer.apple.com/library/prerelease/mac/technotes/tn2206/_index.html
>
>  has a "Table 3  Standard locations for code inside a bundle".  One location is of course Contents/MacOS.  But then the next paragraph says:
>
> "These places are expected to contain only code. Putting arbitrary data files there will cause them to be rejected (since they're unsigned). Conversely, putting code into other places will cause it to be sealed as data (resource) files, causing trouble during updates. Always put code and data into their proper places."
>
> That could be read to mean that Serial.txt living in the MacOS folder is now a No-No for signable code.  And overall, it's maybe going to mean that all external and xcomp packages, the ChartDirector and other frameworks, OmnisPDE.bundle, etc. will also need to be individually signed.  It's a little beyond what firstruninstall fixes - that was good for their v1 code signing scheme but it looks like v2 will require further changes to the traditional Omnis.app package layout.
>
> Kelly
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com
>
>


-- 
Kindest Regards,

Bastiaan Olij
e-mail: bastiaan at basenlily.me
web: http://www.basenlily.me
Skype: Mux213
http://www.linkedin.com/in/bastiaanolij