Using codesign and update from helper app

[ybizeul]

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]

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.

[kornelski]

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]

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?

[kornelski]

It's probably just a limitation of the implementation:

Sparkle/Sparkle/SUCodeSigningVerifier.m

Line 28 in 3f9e50d

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]

I setup DSA signature :-)

[njdancer]

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:

Sparkle/Sparkle/SUCodeSigningVerifier.m

Line 28 in 3f9e50d

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.

[kornelski]

Good to hear DSA worked for you.