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?
These aren’t my pgp keys I’m storing using git-crypt. They’re parts of my configuration that I was (until today) completely content to share unencrypted on my git repo. I’ve simply made them very difficult to see to obfuscate parts of my config that could be used to find my vulnerabilities.
Actual PGP keys, api.key, and stuff of that nature is certainly not in that secrets folder.