Well, it turned out to be not that bad to check the version numbers. The trick 
was to use CFBundleCopyInfoDictionaryForURL so one could get the info.plist 
from the helper tool. In any case, for those who might be interested, I have 
included the code below I used to check the installed helper tool vs. the 
current helper tool version for the SMJobBless sample application. If there is 
a better way, I would be interested.

I suppose one more additional check that might need to be made is to verify 
that a connection to the tool can actually be made if the versions do match. It 
would seem possible that a different tool with the same name and version might 
exist. So, it would seem to be a good idea to check the signing requirement for 
the helper tool. In the case of the SMJobBless sample code, this is what I have 
so far:


-----
-----
SecRequirementRef       requirement;
OSStatus                        stErr;

stErr = SecRequirementCreateWithString( CFSTR( "identifier 
com.apple.bsd.SMJobBlessHelper and certificate leaf[subject.CN] = \"Joe 
Developer\"" ), kSecCSDefaultFlags, &requirement );

SecCodeRef theCode;

stErr = SecCodeCheckValidity( theCode, kSecCSDefaultFlags, requirement );
-----
-----


However, I am not sure how to get the SecCodeRef for the installed helper tool. 
Any suggestions on how I can do that?

Or, is this check not necessary?


-----
-----

NSDictionary*   installedHelperJobData  = (NSDictionary*)SMJobCopyDictionary( 
kSMDomainSystemLaunchd, (CFStringRef)@"com.apple.bsd.SMJobBlessHelper" );
BOOL            needToInstall           = YES;

if ( installedHelperJobData )
{
    NSLog( @"helperJobData: %@", installedHelperJobData );
    
    NSString*       installedPath           = [[installedHelperJobData 
objectForKey:@"ProgramArguments"] objectAtIndex:0];
    NSURL*          installedPathURL        = [NSURL 
fileURLWithPath:installedPath];
  
    NSDictionary*   installedInfoPlist      = 
(NSDictionary*)CFBundleCopyInfoDictionaryForURL( (CFURLRef)installedPathURL );
    NSString*       installedBundleVersion  = [installedInfoPlist 
objectForKey:@"CFBundleVersion"];
    NSInteger       installedVersion        = [installedBundleVersion 
integerValue];
    
    NSLog( @"installedVersion: %ld", (long)installedVersion );
    
    NSBundle*       appBundle       = [NSBundle mainBundle];
    NSURL*          appBundleURL    = [appBundle bundleURL];
    
    NSLog( @"appBundleURL: %@", appBundleURL );
    
    NSURL*          currentHelperToolURL    = [appBundleURL 
URLByAppendingPathComponent:@"Contents/Library/LaunchServices/com.apple.bsd.SMJobBlessHelper"];
    NSDictionary*   currentInfoPlist        = 
(NSDictionary*)CFBundleCopyInfoDictionaryForURL( (CFURLRef)currentHelperToolURL 
);
    NSString*       currentBundleVersion    = [currentInfoPlist 
objectForKey:@"CFBundleVersion"];
    NSInteger       currentVersion          = [currentBundleVersion 
integerValue];
    
    NSLog( @"currentVersion: %ld", (long)currentVersion );
    
    if ( currentVersion == installedVersion )
    {
        needToInstall = NO;
    }               
}


On Sep 30, 2011, at 3:09 PM, Eric Gorr wrote:

> So, it looks like one can call SMJobCopyDictionary with 
> kSMDomainSystemLaunchd and, in the case of the SMJobBless sample code, 
> com.apple.bsd.SMJobBlessHelper to determine whether or not the helper tool 
> has been installed.
> 
> What I am still not sure about is how to check the version number of the tool 
> to see if I need to call SMJobBless again to update the helper tool.
> 
> I suppose I could encode the version in the label of the tool. So, in the 
> case of the SMJobBless code, one might have:
> 
>   com.apple.bsd.SMJobBlessHelper.3
> 
> or something, but I'm guessing there is a better solution then this.
> 
> 
> 
> On Sep 30, 2011, at 1:53 PM, Eric Gorr wrote:
> 
>> That's interesting. 
>> 
>> So, how would one go about checking to see whether or not SMJobBless needed 
>> to be called?
>> 
>> I suppose one would need to check the version number of the installed job 
>> vs. the one in the application package. 
>> 
>> I also suppose one would also try to connect with the helper tool and, if 
>> that fails, then call SMJobBless.
>> 
>> 
>> 
>> On Sep 30, 2011, at 1:40 PM, Kyle Sluder wrote:
>> 
>>> On Sep 30, 2011, at 10:05 AM, Eric Gorr <mail...@ericgorr.net> wrote:
>>> 
>>>> On Sep 30, 2011, at 1:00 PM, Jean-Daniel Dupas wrote:
>>>> 
>>>>> As I understand it, you have to bless the job only once, not at each 
>>>>> launch, so you shouldn't have to request the authorization each time.
>>>> 
>>>> It would be interesting if that is how it actually works, but I am quite 
>>>> certain it doesn't work that way.
>>> 
>>> It does. SMJobBless submits a blessed plist to launchd. It does not do 
>>> one-off jobs. You use once it to install a privileged launchd task that you 
>>> can talk to in the future.
>>> 
>>> --Kyle Sluder
>> 
>> _______________________________________________
>> 
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>> 
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>> 
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/mailist%40ericgorr.net
>> 
>> This email sent to mail...@ericgorr.net
> 
> _______________________________________________
> 
> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/cocoa-dev/mailist%40ericgorr.net
> 
> This email sent to mail...@ericgorr.net

_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to