Tuesday, February 16, 2016

Dotfiles Part 3: Wherein Things Remain the Same

I spent some time trying to get my dotfiles working with git-crypt. I really tried. However, I kept having problems with it. Bad problems, like accidentally committing unencrypted files to my repo. Undoing that means purging and re-writing history, which is a major pain.

Some of these mistakes were my fault. I thought everything was working after a reimaging and restore from backup, but had failed to re-initialize git-crypt so it didn't know it was supposed to  be encrypting or with what keys. However, some were not. One of the problems is that due to the transparent way git-crypt works, a git show will always show you the plaintext changes, so there is no obvious indicator that something isn't going to be encrypted as expected. Git-crypt added a check command because of user feedback, which let's you check to make sure a file is being encrypted on commit. I ran into at least one situation where I checked a file with git-crypt check, and it reported that it would be encrypted, and yet on checkin it was still committed in plain text.

There is just too much danger of accidentally exposing the sensitive files you are trying to keep encrypted for me to have any confidence in continuing to use git-crypt as a solution. Which is a real shame, because the transparency which is its weakness is also its biggest strength. I was able to easily add it into the dotfiles script to handle unencrypting automatically which made it frictionless in normal use, at least on the receiving/installing end of things.


In addition to the problems with encrypting the files, and partly because of them, I also found myself in cases where I needed to update one of my dotfiles quickly in order to be able to finish something I was working on right then. I usually ended up modifying the functioning file instead of taking the time to make the change into the repo and commit it, thus causing the repo version of my files to become out of date which defeats the entire point of keeping them in a repo. Dotfiles is smart enough to make a copy of modified files when re-run, however you are still working against the system you have set up when you do this. One of the reasons I did this was that I was modifying files that I needed encrypted when committed. I also did it because it was simpler and more familiar as it had been some time since I last worked on my dotfiles repo and I wasn't sure how up-to-date it currently was or if there were already untracked changes that I had made. So, it was easier and quicker to add more technical debt to the pile and go back to my work than to stop for a minute and figure out the right way to make the needed changes.

Ultimately, I still need a system to handle these files for me. I haven't decided to move away from dotfiles, although I do find its method of handling cross platform compatibility to be less than I had initially hoped for. I do, however, need to find another solution to encrypting my sensitive files. I know of methods for just using PGP to encrypt before committing them, however they would require me to manually decrypt them every time I wanted to install or update them locally, and that is a huge barrier to usage. Git-crypt just worked on decrypting, but the same thing that made it just work there made it just fail too easily when adding the files.