--On May 28, 2006 3:30:29 AM +1000 email@hidden wrote:
Is the data returned by SecTrustedApplicationCopyData the data defined
at initialisation time (or the most recent
SecTrustedApplicationSetData), or is it the appropriate data for the
application as it is on disk at the time of the call?
It's pretty much the data presented when the object was made. There is (by
design) no updating after that.
In particular, one could make a SecTrustedAppliationRef from a piece of
code on disk, hang on to it for a while, and then do it again to see if has
changed. (In fact, there's a non-public call,
SecTrustedApplicationValidateWithPath in
<Security/SecTrustedApplicationPriv.h>, that does pretty much that.)
I'm just trying to clarify how I can verify the data. Is it safe to
assume every call to SecTrustedApplicationCreateFromPath will return a
new SecTrustedApplicationRef, even if there are existing ref's for the
given path? Can I thus manually verify the application's state by
comparing an older ref against one created "now"?
Yes, every call to SecTrustedApplicationCreate<whatever> makes a new
instance of the object. (There are other ways to get those. For example, if
you explicitly decompose a SecACLRef, you get a bag of
SecTrustedApplicationRefs out, representing what applications are
authorized to access a keychain item. In that case, of course, they
represent what's present in the item's ACL, independent on what might be on
disk at the time.)
Is it even safe in any case to do this manually? I don't particularly
plan on it, I'm just curious. Presumably there's nasty race conditions
with the verification, so it's best to leave it up to the internal
machinery to do it all as necessary. But it might be handy at times to
passively determine the state of an application.
Think of a SecTrustedApplicationRef as instructions that can be used to
verify the identity of some code-like thing somewhere. Comparing two of
those may be well defined, but it's not the same as comparing (say) two
applications. You're comparing two verification instructions.
Oh, and (how do I put this) this stuff is quite likely to change quite a
bit. In a compatible fashion, of course. But any assumptions on what's
underneath are highly likely to get fractured.
As for safety, it depends. It's never secure to validate anything against
stuff on disk unless you have protected yourself against concurrent
modification. (Otherwise the Bad Guy can race you.) It would be nice to
have an API that explicitly dealt with identifying (and tracking changes
to) actual running code. But that's not really SecTrustedApplication's job,
and dragooning it won't make anyone very happy.
Cheers
-- perry
---------------------------------------------------------------------------
Perry The Cynic email@hidden
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
---------------------------------------------------------------------------
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Apple-cdsa mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/apple-cdsa/email@hidden
