Post History
Git is a very good way to sync dotfiles. There are other sync methods, but git also gives you version control, which is the other crucial part of the dotfile approach. Dealing with secrets in git ...
Answer
#1: Initial revision
Git is a very good way to sync dotfiles. There are other sync methods, but git also gives you version control, which is the other crucial part of the dotfile approach. Dealing with secrets in git is not unique to dotfiles. All sorts of projects encounter this issue. For example, a webapp may need to store the database admin password but it is also risky to commit that to git. There are many ways to handle this - you should look for general help about "how to handle secrets in git". As an example, some simple and common approaches are: 1. Somehow isolate the secret into its own file like `admin-password.txt`, and add that file to `.gitignore`. Be careful not to accidentally rename the file and commit your secret. If necessary, create a `admin-password.sample.txt` with a dummy secret to demonstrate correct syntax. 2. Store the secret outside the git repo, such as in `~/secrets/password.txt`. Ensure that the git repo knows the path at which to look for this. The idea is that most of your dotfiles are not that sensitive, so you let git handle those because it will do a better job. The few parts that are sensitive are synced through *some other means* alternative/parallel to git. There are ways of securely syncing secrets that are impractical for a whole git repo, but not for a handful of passwords and such. As a note, you can run your own instance of a Git server, like Gitlab, and create a private repository. This would keep your entire repo reasonably safe. However, if you want high security it is still bad practice to commit secrets to git regardless of the server you use (and even if you don't ever push to a remote). For the secrets, you can use some cloud sync like Syncthing or Nextcloud. Simply ensure that the file sync program is set up on each machine to sync to the same location (you can do this with the dotfiles) and then have the dotfiles look for secrets there. You can also use a public file share such as Dropbox or S3, if you encrypt your secrets and keep the encryption key out of the service. This is generally considered safe, although if you leak the encryption key you potentially also leak the secrets themselves. For that matter, some people encrypt secrets and commit them to git, in which case it's not a big problem. However, you have to keep in mind that if you ever leak the key later, the secret encrypted with that key is still in the git history. That's okay if you're able to respond to key leakage by rotating all your secrets.