Xcode 11 resolving packages fails with SSH fingerprint

ios
#1

Bitrise Build Issue Report template

Description of the issue

Xcode 11 fails to resolve packages (Swift Package Manager) because of SSH Fingerprints check. This is a known issue at Apple and they provide a workaround https://developer.apple.com/documentation/xcode_release_notes/xcode_11_release_notes (see issue #50686014). But the thing is, I can’t get it to work… Does anybody managed to resolve this issue?

Environment:

Bitrise.io: Stack: Xcode 11, macOS 10.14.5 (Mojave)
Step: Xcode Archive and export for iOS

Reproducibility

  • Have an Xcode 11 project that uses Swift Package Manager with private package (like hosted on Bitbucket)

Build log

Fetching git@bitbucket.org:[owner_name]/[repo_name].git
xcodebuild: error: Could not resolve package dependencies:
The server SSH fingerprint failed to verify.

0 Likes

#2

I have just hit this issue and I was able to work around thanks to your reference to the Xcode issue. In my case I have a GitHub hosted iOS project with a private package hosted on a separate GitHub repo. I had to add two steps between the project checkout and building the app:

Firstly I added an ‘Activate SSH key (RSA private key)’ step, setting the ‘SSH private key in RSA format’ to a variable name, eg: ‘$DEPLOYMENT_KEY’ (this has to be done manually in .yml). Then create a secret for that variable with the value of the private key. In my case this the private key for the GitHub Deployment Key for the private dependency.

Secondly as per the Apple workaround, I needed to add an entry to the known_hosts file. This can be done via a ‘Script’ step. For GitHub, you can use:

for ip in $(dig @8.8.8.8 github.com +short); do ssh-keyscan github.com,$ip; ssh-keyscan $ip; done 2>/dev/null >> ~/.ssh/known_hosts

This is working and I expect you can achieve the same with Bitbucket.

0 Likes

#3

We are having the same problem, but I’m happy to say that this workaround works for bitbucket.org as well. Let’s hope that Fastlane or Bitrise can come up with a lane/step that solves this.

0 Likes

#4

A quick follow up and maybe some more help if the above doesn’t work for you.

This workaround worked for our internal dependencies, which depend on each other. However, it didn’t work for the main app, which depends on all of them. The builds once again failed with the fingerprint error.

After digging around without finding anything strange, we added a known host printout build step and could verify that the script did in fact add new hosts. However, the format was off.

Looking into our workflows, we noticed that a line break had made its way into the script. This caused the script to add new hosts with an incorrect format. Removing the line break made this workaround work once more.

0 Likes

#5

Hi there @danielsaidi! :wave:

Can you please send me the URL for a relevant build where I can take a look at your workflow configuration and see what you’ve tried so far? Thanks! :smile:

P.S. That would be a URL starting with app.bitrise.io/build. :smile:

0 Likes

#6

Hi! It was a boy cried wolf situation. The script had been incorrectly added to our app’s workflows. Removing the line break made the workaround work once more.

0 Likes

#7

Glad to hear that everything’s working for you now. :smile:

0 Likes

#8

Ran into another problem with bitrise+fastlane+SPM.

  • Found that using Swift Package Manager with https resolved in missing credentials. Worked around that by pointing to the SSH version.
  • Used the tricks posted by @Dosium to get the authentication and the workaround for Github and Bitbucket
  • Fastlane then failed during dependency resolution. Adding a step prior to the fastlane step, calling xcodebuild -showBuildSettings triggers a resolve dependencies as a side-effect, thanks to https://github.com/fastlane/fastlane/issues/15301#issuecomment-531883355
  • Setting ENV["FASTLANE_XCODEBUILD_SETTINGS_TIMEOUT"] = “30” to avoid fastlane timing out.
2 Likes

closed #9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

0 Likes

opened #10
0 Likes

#11

Thanks for sharing all of that @jakobvi!

1 Like