As far as I can tell, there’s no way around hardcoding email adresses, full names, email server addresses,… inside accounts.email.accounts."account name".
I feel like this is a bad idea. Ideally, I’d want to treat personal info like any other secret, by storing it in encrypted form with the help of sops-nix.
I’m using Thunderbird, so where the contents of this config end up is in $HOME/.thunderbird/profilename/user.js. The closest I can tell could work is letting home-manager generate that file once, then copying it in its entirety into a secrets file, then linking the decrypted file (/run/user/1000/secrets/mail or whatever) to user.js.
Trouble is, at that point Thunderbird itself largely stops being configurable via home-manager itself, since programs.thunderbird.profiles.profilename.settings wants to write to that file as well.
So I guess my problem has to possible solution paths, with the first more preferable than the second:
is there a way to use accounts.email.accounts without putting cleartext info?
or is there a way to append to a nix/hm-generated config file?
Cheers, and thanks in advance to anyone who ansers
If you are generating a file through Nix – it ends up in clear text in the store which is world-readable. Secret management technologies that store the file encrypted in the store do not expect the file to change after it’s been decrypted, i.e. the files are edited, then encrypted, then decrypted, At this point the secrets are readable but cannot be written to.
If you don’t want to publish some details about your account name in a public repository and are using flakes – you can have a private flake define the secrets in a module and then import that module in your public flake.
Alright, thank you, guess that’s what I will do. I have no problem putting that info into a private repo, just don’t want personal information in a public one.
Is this mean that it won’t store your password nor email address on the store if you’ve just installed via package? (e.g., environment.systemPackages = with pkgs; [thunderbird];)
I’m just trying to learn Nix and NixOS, but the secret setup process is looking scary for me, so I’m taking time to learn the fundamentals before getting into important stuff.
Yes, it should then only be stored wherever that program usually puts secrets.
I’m just trying to learn Nix and NixOS, but the secret setup process is looking scary for me, so I’m taking time to learn the fundamentals before getting into important stuff.
Totally get ya. Secrets management was definitely the biggest hurdle.
Some things I would have loved to have known:
“world readable in the nix store” just means “readable for anyone with superuser privileges on YOUR local system” - meaning for some things, that is FINE.
the private flake idea mentioned above is perfect for these kinds of semi-secrets. All my personal identifiable info is in a separate flake in a private repo. It’s not security-critical, so world-readable is OK, but this way it’s not “internet-readable”
getting sops to work is absolutely worth it for actual secrets. You can do it
When I saw that, I was afraid to send some secrets on public because I was using a GitHub repository. Anyway, I learned that if I don’t add any secrets like passwords or SSH keys, I’m okay to use it. However, I also think about WiFi passwords and user passwords stored in the Nix store too? For example, I use this configuration:
# Increase password timeout for sudo
# Allow access on other tty's
sudo.extraConfig = ''
Defaults timestamp_type=global
Defaults env_reset,timestamp_timeout=10
'';
Anyway, this goes to the Nix store and it’s world-readable. Does that mean all sudo setups go to the Nix store too? Because I no longer use normal packages?
No, it means readable for any user, irrespective of privileges, which is why that is such an issue. Storing secrets this way breaks user barriers, so sandboxing no longer works.
This is still “fine” for some use cases, but a lot of Linux security measures intrinsically rely on being able to prevent just any user from reading files. Storing your root user’s password like that defies the purpose of having a root user password, for example.
Does it matter if all your devices’ users can read your wifi password? Probably not, someone exploiting a CUPS vulnerability or getting a low-privilege trojan on your machine likely doesn’t care, but it’s best to keep all your secrets out of the store.
Only things processed by nix will end up in the nix store. So, only things written directly in a .nix file, or imported into nix with builtins.readFile or fetchGit or such, will be put in the nix store.
The nix store is only written to at “build time”, and never changed otherwise. That means that applications which you actually use - such as thunderbird - will not put anything in the nix store.
Another way to express this if “build time”/“run time” is confusing to you, is that if you didn’t write the secret before you run nixos-rebuild, there’s no way nix could possibly read it.
So, if I understand you correctly:
Nix will indeed not touch these secrets. You didn’t write them into a .nix file, or ask nix to read them with builtins.readFile.
The configuration does go to the nix store indeed. You wrote it directly in a .nix file.
That does not mean your user passwords are written into the nix store though. User passwords are unrelated to sudo configuration.
Not quite, no. It’s only in the nix store because you added it to a .nix file. Nix packages still behave exactly as they would on other distros. The only difference is that NixOS configures them to read some files from /nix/store, and puts whatever you define with your NixOS configuration in the nix store.
The packages themselves can still read files from anywhere else if you configure them to do so - and that’s how sops-nix works. Just write your secrets to somewhere that is not the nix store, and tell your programs to read them from there. You don’t even need sops-nix for that, sops-nix just does the writing for you so you don’t have to remember to do that if you reinstall your configuration.
Okay, now I feel that I am close to learning this concept. This is basically an SSH use case for the .ssh/ folder. If I understood correctly now, people use secrets management with sop-nix because they don’t want to deal with the .ssh/ folder. They simply want to manage everything with NixOS or Nix configuration?
Yep, exactly. What they don’t tell you is that they still have to manage the .gnupg folder, because ultimately sops-nix has to encrypt your secrets with keys from that directory. The point is to derive all your other secrets from one, so that you need to manage fewer secrets - kind of like a password manager for your OS configuration.
As an aside, I wouldn’t suggest putting your ssh secrets in sops, you might as well use a gpg key for ssh auth directly instead of encrypting your ssh key with a gpg key…
Thank you so much. You just relieved my frustration because my second voice is telling me all the time “you are dumb, you can’t learn Nix, just give up”.
I am thinking about using Sop-Nix because I am basically copying configs from nyabinary but I don’t use it for now because I don’t know . In some point I would like to learn it but I am still trying to learn NixOS and Nix, even though I am struggling to set up Firefox home-manager .
