Have you ever committed a secret to a codebase? You aren’t the only one. Options exist out there to help you scan your codebase for such secrets, prevent you from committing them in the first place and to manage secrets from writing code to builds and deploys. A great rundown of those methods can be found here.
I write mainly for iOS, and I want something as lightweight and simple as possible to simply replace templated strings in my codebase with the appropriate values. I’ve used
cocoapods-keys for some time, and it fulfills its use case very well, but it only works on secrets that are used in your application’s executable code. This means any sort of build environment tools (like Xcode Build Phase scripts) that require secrets, or things that want to use Plists, won’t be able to use it.
I wrote a script to do a basic search-and-replace throughout a codebase and swap template values for actual credentials. The template values are enumerated in a file that you commit to your codebase, paired with another file that contains the actual secret values, in
.psst/values respectively. The separation makes gitignoring the secret values file easy. If no secret values file exists, the script will try to expand environment variables of the same name, a common workflow for CI setups. (Optionally, a path to a keychain can be supplied, if you prefer to check in your secrets to the codebase in a securely encrypted file.) It will then iterate through the keys with secrets in hand and perform the replacements.
Check out the source code or get it on homebrew:
brew tap tworingsoft && brew install psst (in fish,
brew tap tworingsoft; and brew install psst)
OK, mistakes happen. This is a software tool, and it’s being used by humans. If you find you’ve still accidentally committed sensitive data to your codebase and pushed, it’s out there forever. Don’t bother trying to rewrite your git history–immediately rotate that credential!
Enjoy the post? Please help support more like it by buying me a cup of coffee!