.dots VS agenix

I have a wrapper function that just maps to dev to make life easier: https://github.com/dmadisetti/.dots/blob/template/dot/config/fish/functions/develop.fish

Never fully got it to work, so I just encrypt my secrets when I build my isos: https://github.com/dmadisetti/.dots/actions/runs/5055636638/jobs/9072093945

I have multiple files for each machine based on hostname. I have CI strip my config of all system specific information for general distribution. For reference: https://github.com/dmadisetti/.dots

I build a wsl image: https://github.com/dmadisetti/.dots/blob/template/nix/machines/wsl.nix

What I do: Keep secrets in a separate git repo as a flake, and have a stub flake, that can be overridden: https://github.com/dmadisetti/.dots/tree/template/nix/spoof

My dots

I have a script that will symlink my dotfiles in (github:dmadisetti/.dots/setup.sh), because you also end up with weird RO permissions if you do it through Nix. I think this is fine. It also means that you aren't stuck with Nix

The way I manage multiple systems is with a wrapper: https://github.com/dmadisetti/.dots/blob/template/dot/config/fish/functions/snix.fish

The only thing that is semi manual is setting up disks on first install (something you'd still have to do with arch). You can still script that: https://github.com/dmadisetti/.dots/blob/template/scripts/run-install.nix.sh

How about: https://github.com/ryantm/agenix

I've heard good things about and seen sops-nix used on a few really solid configs. Others tend to use Age or Homeage.

I don't have a write-up, just my code in git. But it's not public. I'm not using anything out of the ordinary - Nix containers, modules, and functions, and the Agenix module with uses a private key to decrypt secrets at start. The Nix language is inherently composable. Here are some links that explain:

Containers:

https://nixos.wiki/wiki/NixOS_Containers

Modules:

https://nixos.wiki/wiki/NixOS_modules

Functions:

https://www.reddit.com/r/NixOS/comments/zzstun/please_help_m...

Agenix:

https://github.com/ryantm/agenix

For passwords I am using agenix which is also pretty awesome, an alternative could have been sops.nix.

Alternatively, you could simply add the wireless connection files to the Networkmanager dir in /etc using environment.etc. Though keep in mind that any file declared in your config is readable by any user in your system. agenix would be the solution to that.

One think I saw that I don't recommend is to change your password after installing; that's not very reporoducible, use users.users..hashedPassword or users.users..passwordFile with agenix or sops-nix.

Answering your broader question (secret management) colmena does that for me outside the Nix store. I also use git-crypt to store secrets in the repo. There are also more Nix-y alternatives like agenix.

I feel that trying to make SSH keys short-lived is becoming more painful each year because there's an increase of tools that use SSH keys for purposes other than SSH logins. For example, age [1] encrypts files with SSH keys, agenix [2] does secrets management with it, Git can now sign commits with it [3], and even ssh-keygen can now sign arbitrary data [4]. All of these become useless the moment you start using short-lived keys.

[1]: https://github.com/FiloSottile/age

[2]: https://github.com/ryantm/agenix

[3]: https://calebhearth.com/sign-git-with-ssh

[4]: https://www.man7.org/linux/man-pages/man1/ssh-keygen.1.html

I built this because I try to keep as much as possible outside of my system config but all of the secret managers I found were system only. I had no idea how to solve this until I found RaitoBezarius' awesome pull request to agenix where it all clicked. It also exposed me to the inner workings of home-manager which has definitely made me appreciate it more! I kept this separate from agenix because I am interested only in a module rather than a CLI and thus see it as having a different fit.

I've been thinking about the same thing. I haven't gotten around to it yet but agenix looked the most promising to me so far