Re: Are You Sure ?
Re: Are You Sure ?
- Subject: Re: Are You Sure ?
- From: Bill Cheeseman <email@hidden>
- Date: Thu, 13 Nov 2008 11:54:07 -0500
- Thread-topic: Are You Sure ?
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.
The Plug-Ins folder is one folder that is not sealed (or directly sealed) to
the main executable, precisely because users are often expected to be able
to add or remove plug-ins without triggering a security warning.
When they say that "helper tools" should go into the executable directory,
they mean "tools" in the technical sense; that is, non-bundled (single-file)
executable code. Those are not expected to be user-changeable, so it is OK
to seal (or directly seal) them to the main executable.
Helper "bundles" are different from helper "tools" in that helper bundles
have subfolders, some of which I suppose might be user-alterable. Therefore
helper bundles should go at the root level of the main application package's
Contents folder, which is not sealed (or directly sealed) to the main
application executable. They should be separately code-signed in their own
right.
Clear? Ha! I agree that the documentation team should be given a shot at
these documents, in order to clarify the overuse of abstruse technical terms
that aren't defined for the benefit of first time readers.
> Perhaps I DO want my helper application bundles to be (directly)
> sealed to the main executable without being separately sealed, so I DO
> want to put them in the Resources folder. ???
I think not. I believe this will lead to execution problems, if not now,
then in the future as the code signing technology becomes more sophisticated
and moves from its current role as a warning-only protective technology to
something that takes a more active security role. That is, your helper
bundle might not execute at all in a future version of the OS if you put it
in the wrong place.
> What is the "executable directory"? Is it /Contents/MacOS/ ? This
> contains the main executable, which I presume is "in the seal". Is
> everything in this folder also "in the seal"?
In Mac OS X, yes, the executable directory is the MacOS directory. I believe
everything in it is sealed to the main executable.
> And what is the "support directory"? There is no /Contents/Support/
> folder.
I don't believe there is a "support directory." That's why I complained
about the ambiguity of this terminology in the Tech Note in my last post.
(Another job for the documentation team.)
> Other documents, "CodeSigningGuide.pdf" and "Technical Note TN2206_
> Mac OS X Code Signing In Depth.pdf", don't make this any clearer. The
> writers of these documents knew exactly the meaning of their jargon
> and, I'm sure, have written a perfectly understandable document. The
> reader is left confused, however.
Amen.
> I will keep an eye on codesigning, but I not going to use it until it
> is explained so I can understand it completely. (If I were still
> teaching mathematics, something like this would require more homework
> and a complete rewrite.)
Code signing is one of those technologies Apple has become fond of making
public before their time. I assume the idea is to give us developers an
opportunity to get our applications ready for the future before the future
arrives. But, as you've seen, it's hard work because the technology changes
as it moves toward maturity.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
www.quecheesoftware.com
PreFab Software - www.prefabsoftware.com
_______________________________________________
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