Figure out a better way to safely store api keys about old-balance-ios

[ricburton]

Check if keys are missing before pushing to Testflight :P

[jamierumbelow]

Can we pull them from a server (AWS Key Management?) on initial load, then put them into the keychain?

[einsteinx2]

Not sure how that could work on a client app. In a server app, it implicitly has the credentials to pull the keys. In a client app we'd have to include the AWS credentials in the app and then anyone could pull our api keys. Also if they're loaded via network, it's trivial to MitM even if it's SSL, so anyone could just grab the keys that way too.

It could be argued that they could just grab the keys from the app binary or app memory, but at least it's a bit harder especially if we use a key obfuscater in the app. The main problem we're solving here however is to just not have them checked into git, but using any online key management server would necessitate checking in those keys to make it work, so we end up with the same problem of how not to include those keys in git...

[wolffan]

If we can develop with no keys.
Put the keys into circle ci or any other service and use it to ship to appstore.
No one has the keys

[einsteinx2]

@wolffan for Ethplorer at least I have hard coded in the default free key when there are no keys found. So if you can set up CircleCI or another service to do the app store builds then that word work ok, but the reality is we do need to test using real keys (things like intercom), so having some way to store them locally without checking into git would be ideal.

I'm starting to think maybe we can use an Xcode custom build step to parse a file that is not included in the workspace? That way we can gitignore it and not break the project.

[wolffan]

yeah as well,

[einsteinx2]

@wolffan was your comment meant to continue? haha

[zackshapiro]

@einsteinx2 One way to do it is the following

• Create Debug and Release plist files with keys and blank values or placeholder values
• Don't gitignore them
• In your AppDelegate, check the values for the keys and if the value is present, start the appropriate service

Something like:

• fetch plist file
• look for key, cast to String!
• if cast works, start the service that's needed for the key, else, don't start the service
• only give keys to those who need it

I did this in a past commit for the Nano iOS Wallet:

        // Instantiate Crashlytics if APIKey and Secret are present
	        if let path = Bundle.main.path(forResource: "Info", ofType: "plist"),
	            let root = NSDictionary(contentsOfFile: path) as? [String: Any],
	            let fabric = root["Fabric"] as? [String: Any],
	            let _ = fabric["APIKey"] {
	            Fabric.with([Crashlytics.self, Answers.self])
	        } else {
	//            print("No API Key Present")
	        }

[einsteinx2]

@zackshapiro I'm essentially doing this now, but with a single plist. How does this end up working? If we're not git ignoring the release file, then when we update it to push a release it could get checked in right? Or am I missing something? Can you elaborate a bit on how this would be different from just using a single plist with blank keys and giving them only to people that need them?

Also the other problem is that it would prevent testing using the API keys in debug mode which may be necessary at various times (and in general I like developing as close to the release version as possible). Then if we throw the real keys in the debug plist for testing, for sure they'll be forgotten at least once and committed haha.

[einsteinx2]

Taking this out of the app store milestone as it needs more time and isn't user facing.

[einsteinx2]

Going to go with this solution for now: https://medium.com/flawless-app-stories/secret-variables-in-xcode-and-your-ci-for-fun-and-profit-d387a50475d7

Though I'm going to hold off til app store release is ready to save time.

For now, the apikeys.plist file is git ignored, so when you want to submit or just test with real keys, drag it into the project and at worst if you check in the change to the project, other devs just have to delete the missing reference from the file list in Xcode to get it building. The apikeys.plist file will never accidentally check in.

Seems like an ok compromise for now.