Re: Are You Sure ?
Re: Are You Sure ?
- Subject: Re: Are You Sure ?
- From: Luther Fuller <email@hidden>
- Date: Thu, 13 Nov 2008 11:25:34 -0600
On Nov 13, 2008, at 10:54 AM, Bill Cheeseman wrote:
on 2008-11-13 9:57 AM, Luther Fuller at email@hidden wrote:
I've ben rummaging thru some documents on codesigning. One of them,
"Code Signing Release Notes_ Code Signing Release Notes for Mac OS X
v10.5.pdf" contains this ...
Check the last revision date, and compare it to the August 2008
revision
date of the Tech Note I cited yesterday. Code signing is in its
infancy, and
it is a moving target. Instructions have already changed a couple of
times,
and the obsolete instructions don't necessarily get taken down in a
timely
fashion. As far as I recall, the Tech Note is the most recent.
What To Avoid
...
Do not put helper applications, plugins, and other separately signed
code into the Resources directory of a bundle. The Resources
directory
is directly sealed to the main executable. Put plugins into the Plug-
Ins
directory. Put helper tools into the executable directory. Put helper
applications (with their own bundles) into the support directory.
Is "directly sealed" different from "sealed"? The document doesn't
say.
I don't think there's a difference. What they're driving at is that
you
don't want user-changeable files within the main application package
to be
sealed (or directly sealed) to the main executable, because then a
user's
change to the embedded file would be seen as a security breach
(meaning that
the system will warn the user that the application has been tampered
with
since the developer released it). You must therefore put user
changeable
files somewhere that is not sealed (or directly sealed) to the main
executable.
My helper application bundles have a very few lines of code in them
and contain nothing that is user modifiable, so perhaps it would be
appropriate to put them in the Resources folder.
This suggests another problem. Neither my main application nor the
helper applications contain any global variables. They do contain
properties, but these values are never changed in the script. Data
that the user creates are stored in the preference .plist file, which
is where they belong. I am now lead to the conclusion that if one were
to write an application bundle in AppleScript, codesigning would fail
unless globals and modifying of properties were avoided.
I have tried again this morning to reproduce the warning that started
this discussion, but was unable to do so. The main application issues
the warning the first time it's run after download, then everything
just works as expected. Again, I think I will just wait and see what
happens before jumping to codesigning.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden