-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Does sparkle have a plan if deprecated functions are removed? #558
Comments
The modern way is to use SMJobBless API to perform privileged operations. This has a few consequences though. One is that it requires a helper tool that must be in the app (it can't be in the Sparkle framework). Another is that it requires code signing and I believe for the identity to be specified in the app's info plist. I believe the API copies the helper tool somewhere in /System (which also can handle updating the tool), so every Sparkle based app would have their own helper tool installed somewhere into there. This would probably only be necessary if a privileged operation needs to occur though (which isn't the common case). I think Sparkles operations are simple enough where we don't need any fancy kind of IPC. Side note: the authorization and file moving/copying code needs to be somewhat rewritten IMO. A bunch of deprecated APIs are being used (evident if you increase the deployment target), unnecessary app copies are done, update installations can be incomplete, many bits of code can be replaced with a Cocoa equivalent. |
My overall vague plan is to rearchitect Sparkle from "update yourself" approach to "update that bundle". When Sparkle can update apps that it's not running in, then it'll be easy to make it a helper app. But, it's hard, e.g. lots of things are tied to delegates or |
I'm currently working on a rewrite of |
I took a look at
Since this seems pretty similar to supporting sandboxing (#363) and is potentially more difficult, it may make more sense to do sandboxing first. |
We don't use AuthorizationExecuteWithPrivilages anymore. We do use SMJobSubmit but there is no viable replacement with acceptable trade-offs (one-off launchd jobs + option to run non-root agent instead of daemon + not making integration extremely complicated). So the plan to move away from deprecated APIs in general are when alternative APIs become viable.. Until then, it's not like they can just be removed from the OS. |
specifically:
AuthorizationExecuteWithPrivilages
?The text was updated successfully, but these errors were encountered: