Skip to content
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

Insecure update error warning when running tests, as tests are never code signed #680

Closed
clausjoergensen opened this issue Nov 9, 2015 · 7 comments · Fixed by buildasaurs/Buildasaur#235

Comments

@clausjoergensen
Copy link

I'm having a problem with linking Sparkle and running UI/Unit tests from a unsigned unit-test target. Sparkle shows a popup about "Insecure Update" when executing the tests from command line, which blocks the test executing completely.

Is there any flags or settings that would prevent Sparkle from attempting to update when running a test (or maybe even DEBUG) target? I've tried disable auto updating in the Info.plist without any luck

@kornelski
Copy link
Member

In the Info.plist setting SUScheduledCheckInterval to 0 should stop automatic updates.

Alternatively you can set SUEnableAutomaticChecks to NO in app's own NSUserDefaults.

@kornelski
Copy link
Member

#670

@czechboy0
Copy link

Same issue here, during tests the modal still shows up and hangs my tests. I tried changing the plist values and returning false to SUUpdater's func updaterMayCheckForUpdates(updater: SUUpdater!) -> Bool, but none of it seems to work.

What is the recommended setup for apps that have unit tests?

czechboy0 added a commit to buildasaurs/Buildasaur that referenced this issue Feb 4, 2016
- keychain keeps different keys for release and debug (we were getting a dialog bc release was codesigned and debug wasn't)
@kornelski
Copy link
Member

It looks like Apple's solution for this, via Xcode's automatic code signing, is to sign everything, even for tests.

@zorgiepoo
Copy link
Member

It looks like Apple's solution for this, via Xcode's automatic code signing, is to sign everything, even for tests.

I really don't buy that; in fact I think there's a recent trend to not set up signing info at all. I think if DSA signing was used, Sparkle wouldn't prompt up a dialog here.

@mokagio
Copy link

mokagio commented Jul 7, 2020

Is there any update on this issue? I just took over maintenance of an internal macOS app and I'm trying to add tests but getting this same error.

I'm running the tests with this syntax:

xcodebuild clean test \
  -workspace 'Autoproxxy.xcworkspace' \
  -scheme 'AutoProxxy' \
  CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO

I can make them pass locally by using CODE_SIGN_IDENTITY="Apple Development", but that fails on CI, obviously, because it doesn't have access to our certificates.

I tried @kornelski suggestion by passing -SUEnableAutomaticChecks=NO and SUScheduledCheckInterval=0 but neither worked.

Thanks for your help 🙏

@mokagio
Copy link

mokagio commented Jul 10, 2020

Inspired by the commit @czechboy0 linked, I worked around the issue like this:

// There are instances in which we might not want to run Sparkle, for example when running
// the tests via xcodebuild in CI due to a blocking alert related to code signing.
// In such cases, one can pass the `SKIP_SPARKLE` preprocessor definition and not have Sparkle
// launched.
//
// Using a "skip" flag plus an "if not defined" means that there are no changes to the setup for
// debug and release builds; only those who wish to no have Sparkle need to do extra work.
//
// See https://github.com/sparkle-project/Sparkle/issues/680
#ifndef SKIP_SPARKLE
    self.updater = [SUUpdater sharedUpdater];
#endif

And updated my xcodebuild invocation to:

xcodebuild clean test \
  -workspace 'Autoproxxy.xcworkspace' \
  -scheme 'AutoProxxy' \
  CODE_SIGN_IDENTITY="" CODE_SIGNING_REQUIRED=NO \
  GCC_PREPROCESSOR_DEFINITIONS="SKIP_SPARKLE=1"

This works alright for me 👌

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants