Nixos-build (flake) can't read a file in a submodule

Hello

I have a working nixos-config repository that uses flakes. I would like to maintain it as opensource code but I don’t want to push secrets, even if they are encrypted with agenix and age.

My plan was to create a private repository and use it as submodule in the public one but since I moved the secret in a submodule flake stopped working saying that it can’t find the secret file anymore.

gianarb@huge ~/git/nixos-config  (main) $ nixos-rebuild build --flake ./machines/lab-generic-netbooting#pixiecore-dispatcher
building the system configuration...
error: getting status of '/nix/store/c3wr27ashyc1762spj6lri7dyqgpn8pi-source/secrets/secrets': No such file or directory

I looked at the '/nix/store/c3wr27ashyc1762spj6lri7dyqgpn8pi-source/secrets (in theory the submodule) and it is empty. Not sure if it is an expected behavior and how to I can workaround it. I am open to look at other ways to keep my config open but the secret private.

Thanks a lot

1 Like

I had a similar goal in mind (not wanting to expose my secrets publicly, even encrypted). The flake submodules story wasn’t in the greatest shape for a while, that said you can try it if you want, but you have to use git type flake inputs and also set inputs.<name>.submodules = true, at least that’s how it was the last time I tried it.

What I did instead was simply define a home-manager module that imports a private repository with builtins.fetchTree like so. You’ll need to setup credentials for Nix to actually be able to pull it with the nix.conf access-tokens setting or a netrc file.

1 Like

This doesn’t seem to be currently supported: nix flakes: add support for git submodules · Issue #4423 · NixOS/nix · GitHub

That said, do yourself a favor and stay away from submodules. I wanted to write a rant about how unintuitive they are, but that’s my entire point, and we don’t need yet another thinkpiece on that, the internet is full of them (and git wrappers like repo that try - and mostly fail - to fix it because big orgs like using them so much).

I’d suggest just making your secrets repo a flake input. It doesn’t need to have a flake.nix, you can add it with flake = false and then refer to files inside of it with ${secrets}/secret.gpg or whatever, assuming you named the input “secrets”.

--override-input is a very handy flag to know about if you do this kind of thing, since it allows overriding a remote input with one on your current machine.

4 Likes

I should have outlined that the reason I didn’t do this is because it then makes the entire repository fail to evaluate if a user doesn’t have credentials to pull that one input. The way I have it alternatively, so long as the user stays away from my personal hm module, they can re-use whatever they want from my flake without needing credentials.

Hm, interesting point, though a user could also use follows so they don’t need access to your personal input.

Yeah, that’s also true, but not necesarily intuitive. This way I can share things by just sending people simple commands, e.g. nix shell github:nrdxp/nrdos/locked#helixto share my editor and it’s configuration (which I often do since it had good defaults for Nix) . It might be a tad much for newcomers if it was nix shell github:nrdxp/nrdos/locked#helix --override-input secrets github:divnix/blank, for example.

Then you could point this input to blank flake in flake.nix for others and use --override-input secret git://mysecretrepo yourself.

Thank you for sharing! I do my best to stay away from submodule as often as I can but with my limited knowledge of Nix and Flake it was the easiest solution I was able to come up with!

I will try using the private repo as flake input. right now I don’t know reusability is important in my scenario, I just feel like I want other people to read what I do and learn from it as I learn from other repositories out there.

Thanks a lot