OSX Installer

Bo Carleö mail at corbisoft.com
Wed Aug 20 12:21:41 EDT 2014

Hi Bas

My understanding is that code sign checking only occurs at install time
and only on packages downloaded over the net.

Any changes of installed data or the lib itself after that doesn’t matter.
Eg I allow users to change report margins - which means a change to the lib,
without any protest from Gatekeeper.


20 aug 2014 kl. 07:39 skrev Bastiaan Olij <bastiaan at basenlily.me>:

> 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
> _____________________________________________________________
> Manage your list subscriptions at http://lists.omnis-dev.com

More information about the omnisdev-en mailing list