I have a config that I share on github. I share the whole thing and there are keys in it but they are obviously not the complete key (as is standard throughout the community). Just enough to point to the real key with Nix.

Anyway, I have finally gotten around to learning the power of git-crypt. Today, I went through my whole config and took everything out that could even remotely be used by a hacker to find out security holes in my config (permitted insecure packages, specific hardware ID’s, github username and email address, for example all went into nix files into the secrets folder with imports where they used to reside) and put those files into a folder at top level called secrets. Then, I encrypted all of the files in that folder and pointed the rest of the config to them so they remain encrypted on my github but perfectly usable in evaluation and build of my config derivation.

My question is: Have I done something clever that will significantly decrease the chances of exploit or do you recommend that everyone does this and I’m just late to the security party?

If this technique is just standard, what else could one do to harden their system without causing difficult to solve issues on deployment of their config? For example, I now need to decrypt that folder when I use that config on a new system and anyone else building it wouldn’t be able to get through the evaluation.

I’ve heard of Sops-Nix and other such security handlers. How can I use sops-nix to aid in that initial git-crypt setup when I spin up a new system, for example?