Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Using codesign and update from helper app #285

Closed
ybizeul opened this Issue Jul 1, 2013 · 7 comments

Comments

Projects
None yet
3 participants

ybizeul commented Jul 1, 2013

I'm trying to run the update check from my helper app. I'm getting the path to my app bundle and get its SUUpdater.

But I constantly get an insecure update warning, the test in Sparkle code makes sure that the current bundle is the main bundle to use developer certificate. What is the reson for that ? Can I use developer certificate (and not DSA keys) if I'm checking for update from a helper background app ?

njdancer commented Oct 4, 2014

Hey ybizeul, I'm having the same issue while trying to use sparkle from within a preference pane. Mainbundle refers to system preferences which is not the bundle I am trying to update. In some circumstances I am even trying to update a preference pane from a helper app that is distributed within. Did you ever find a workaround to this?

I'm not quite sure I understand the reason behind checking that the bundle calling the update is the mainBundle. I guess I feel like sparkle should compare the signature of the bundle it is initialised with to the bundle that it has downloaded regardless of what process that check is running within.

Owner

pornel commented Oct 4, 2014

We support apple code signing only for simple app in zip updates.

Everything else - plugins, pref panes, installers MUST use DSA signatures.

We can't verify Apple's code signature identity unless it's used to sign main (and the only) app bundle running.

njdancer commented Oct 4, 2014

Fair enough. I guess i'm just unsure why that is the limitation. Does OS X not allow you to compare the signatures of two arbitrary bundles or can you only compare another bundle with the current? Seems like this may be more a limitation of the current implementation than anything else. Would you be willing to accept a pull request if this functionality can be implemented or do you have a reason why this shouldn't be done?

Owner

pornel commented Oct 4, 2014

It's probably just a limitation of the implementation:

result = SecCodeCopySelf(kSecCSDefaultFlags, &hostCode);

so PRs are welcome. It is a security-sensitive code though, so it needs to be possible without any risky hacks.

ybizeul commented Oct 4, 2014

I setup DSA signature :-)

njdancer commented Oct 5, 2014

Agreed. I'm not that invested. I can setup DSA signatures without much trouble. It just seems to me that as these bundles already have signatures embedded including another in the app cast is asking for trouble. On top of this it seems like it shouldn't be much trouble to compare the signatures of two arbitrary bundles but I don't necessarily have a lot of experience with this so may be mistaken. At this stage we can probably close this issue and if a PR comes this can be considered additional functionality. Unless you would like to keep it around as an open feature request.

On 4 Oct 2014, at 6:29 pm, Kornel notifications@github.com wrote:

It's probably just a limitation of the implementation:

result = SecCodeCopySelf(kSecCSDefaultFlags, &hostCode);

so PRs are welcome. It is a security-sensitive code though, so it needs to be possible without any risky hacks.


Reply to this email directly or view it on GitHub.

Owner

pornel commented Oct 15, 2014

Good to hear DSA worked for you.

@pornel pornel closed this Oct 15, 2014

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment