Allow non-admin accounts to update QS in protected directories. Fixes #521

[pjrobertson]

Finally :)
Only took me all weekend…!

Background info on Auth:

Apple is deprecating everything under the sun that allows apps to run in a 'privileged' environment. The currently recommended way is to use a helper app and communicate with this app using XPC or similar (NSMachPorts). See the SMJobBless example project for a little more info.

I chose to use Sparkle to deal with our authentication problems as I thought I'd be an easy solution, unfortunately, they are also using the deprecated methods (as of 10.7) for authentication. Looks like they haven't gone down the route of privileged helper apps (which require independent code signing… ugh!) yet.
I've decided to stick with it. The methods are deprecated, but hopefully if we still close to Sparkle this method won't die too soon

Background on Sparkle:

Since Sparkle is such a large framework, and we only really need one method, I have removed the submodule and added only the required (and butchered) files.
The files have been modified as little as possible, just enough so we don't have to #import the whole project. Hopefully they're still mostly intact that we can easily alter them as Sparkle alter their files.

So background aside, this pull means non admin users can download an update of QS to a protected directory, and be prompted with a dialogue asking for an admin password.
You may notice that in QSUpdateController the following steps are taken

• Mount the .dmg in a temp folder
• Copy the Quicksilver.app file in the .dmg to a temp folder in Application support/Quicksilver
• Chown the Quicksilver.app file from step 2 to give it the right permissions
• Copy the file from step 2 over the current install

The reason for step 2 is that the .dmg temp folder is read-only, so chown and move methods don't work on it (What Sparkle uses)

---

To test this:

• Change the build number in Developer.xcconfig to say 3920
• build and install in /Applications
• Log in as a non admin user and run Quicksilver
• Update from in the app

Sorry for the epic pull message, just… there's a lot to say, and a lot of reasoning behind the few changes!

[pjrobertson]

P.S. you may need to rm -rf …/Sparkle before you attempt to merge this, sorry

[skurfer]

Just trying it under my normal account to start and I get "It was not possible to decompress downloaded file." It appears to download something, but I'm not sure where it's dumping the file, so I can't verify.

Also, probably outside the scope of this pull request, but nothing in QSUpdateController is localized. :-)

[pjrobertson]

I've only touched the - (NSString *)installAppFromDiskImage:(NSString *)path method, so I suggest adding a breakpoint there and seeing if it gets triggered/seeing what happens after this.

[skurfer]

OK, updating from my admin account works. Trying with a non-admin user will have to wait until later.

[skurfer]

I got a chance to test this and it seems to work as advertised. I am concerned about these two lines:

[manager removeItemAtPath:tempDirectory error:nil];
[manager removeItemAtPath:tempHoldDir error:nil];

Both of those paths are created using [NSString uniqueString]. It should never happen, but if for some reason that method returned nothing, those two lines would remove some things they shouldn't. Could we either test that they don't equal what should be their parent directories, or just hard-code some sensible value like @"QSApplicationUpdate"? Or maybe examine the error when creating the directory instead of passing nil? (We should probably be doing that in any case for something like this.)

Also, I see that setUpdateTimer returns tempHoldDir, but the path referred to by that string was just removed a few lines earlier, so what good does it do?

All in all nice, though. :-)

[pjrobertson]

Good points, I've made the changes as you suggest.

Also, I see that setUpdateTimer returns tempHoldDir, but the path referred to by that string was just removed a few lines earlier, so what good does it do?

I assume you meant

-(NSString *)installAppFromDiskImage:(NSString *)path;

Returning anything signals to the calling method that it went OK. Probably having a BOOL is as simpler option, so I've done this

[skurfer]

I assume you meant

-(NSString *)installAppFromDiskImage:(NSString *)path;

Yeah, sorry. Xcode doesn't parse that file correctly for some reason, so it was showing the wrong method up top.

Code looks good, but enough has changed that I feel like I need to actually test the process again, so I'll try to do that later.

[pjrobertson]

Code looks good, but enough has changed that I feel like I need to
actually test the process again, so I'll try to do that later

I was going to, but my head started hurting so I went back to bed. I hoped
you would ;-)

Thanks

On 25 October 2012 13:21, Rob McBroom notifications@github.com wrote:

I assume you meant

-(NSString *)installAppFromDiskImage:(NSString *)path;

Yeah, sorry. Xcode doesn't parse that file correctly for some reason, so
it was showing the wrong method up top.

Code looks good, but enough has changed that I feel like I need to
actually test the process again, so I'll try to do that later.

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/1159#issuecomment-9775383.

[skurfer]

Anything to keep me away from these plug-ins. I hate dealing with compilers and headers and crap. :-)