1. 9

My dotfiles are publicly accessible at https://github.com/stig/dotfiles, and for the most part I’m happy with that. These days my config is managed with Nix’s home-manager.

I’ve been using my current email address for about 20 years, and over the years have used it with lots of public mailing lists. Now I get so much spam, and am in the process of changing my primary mail address & email hosting to address this.

So the first question is: does it make sense to not put the new address in a publicly available GitHub repository? Or is that unlikely to be a place spammers harvest email addresses from?

Assuming the answer to the first question is “yes”, the next question is how do you hide some of the config (e.g. anything under home-manager’s accounts.email) with Nix?


  2. 4

    sops-nix supports home manager now. Also consider what email you use for git commits. While github hides the email, it’s still publicly accessible.

    1. 3

      I use chezmoi to manage my dotfiles and I can set it up to use my Bitwarden vault to put secrets in config files.

      1. 1

        Came here to say this; I don’t use the functionality myself, but you can also encrypt entire files with Chezmoi using gpg or age and it will transparently decrypt/encrypt them on your host: docs link

        1. 1

          +1 for this, I had chezmoi wired up to pull secrets from 1Password until I moved to nix (but my nix config isn’t public… yet.)

        2. 3

          home-manager supports sops-nix, that way you can encrypt whatever part you want. personally I prefer to use agenix, but that lacks support for home-manager.

          1. 3

            I have a hardcoded symlink named private going into a dotfiles.private private repository. No secrets there though, but commands/aliases internal to my current company that I don’t want the whole world to know about.


            1. 2

              You could encrypt it, for example using git-crypt.

              1. 2

                I ultimately settled on simply having two repositories, configured in a single local repository as two remotes. It’s a bit of a kludge, but it seems to work reasonably well. There’s two branches, which each point to a branch of the same name on different remotes:

                  main    fe1b2870 [github/main] Update oh-my-zsh submodule to latest sources
                * private 61f43032 [nexiom/private] Update oh-my-zsh submodule to latest sources

                In my case I use different Git servers as well, but it could be the same Git server hosting two repositories, one with tighter access control. As a precaution, I also have a private branch on the “public” repository with a single commit and force push protection to avoid accidentally pushing the private branch to a branch of the same name on the “public” remote.

                The only other thing to keep in mind is inevitably the branches have different history as the private branch is a superset of the commits on the public branch. Even that’s not technically true, as there’s some cases where files actually have different content beyond a mere subset of content (e.g. different .gitignore files). In the interests of keeping each branch history clean, I’ve settled on just cherry-picking relevant commits into the “public” branch:

                > git rev-list --count main
                > git rev-list --count private

                Suffice to say, I’ve spent way too much time over the years curating my dotfiles.

                1. 1

                  For what it’s worth, this is what I ended up with:

                  • Put a “Hide My Email” disposable email alias in my public config. (I don’t care if people know the provider.)
                  • Create a new local branch with a single commit that I rebase on top of the public branch, which replaces all the uses of the alias with my actual address.
                  • On the remote side of the “local” branch I put an empty branch, with branch-protection so I can’t accidentally push to it.
                  • I also created a pre-push git hook to further ensure that I can’t accidentally push any commits with my actual email address in to any branch
                  1. 1

                    I end up using some local file references, e.g. git config --global include.path .gitconfig_local and source ~/.env.local. Those files on any other computer are sync’d using an environment-specific cloud storage tool like OneDrive or Dropbox or Syncthing. Sometimes, I’ve set up specific environments to pull from secrets storage tools.

                    1. 1

                      I usually avoid putting anything “sensitive” as plain text in my dotfiles. Sensitive is very flexible term and depends on whatever you want to not be public (passwords, keys, IPs, etc.). I put those in different repository that is managed & encrypted using gopass. That way I just read them into my environment when I need them using the gopass cli.

                      I don’t use home-manager just yet.

                      1. 1

                        I use a git submodule pointing to a private git repo and I think I import it conditionally. To be able to build without it, using github actions.


                        Note that I also use sops-nix for some stuff too.

                        1. 1

                          I have a ~/.config/something/.profile.pre and ~/.config/something/.profile.post in my zshrc and I put all the secrets or specific aliases in there, per machine - those are not under source control (or let’s say, public, I do have some snippets saved somewhere) - and these change so rarely that I deliberately don’t version or automate that. Has been working fine for me for many years. Realistically it’s only a couple of lines for my main 2-3 machines and zero for all the others/servers.

                          1. 1

                            I have a script that prompts me for my email address and username the first time I run it. I use that input to set my git email alias.