Add a default.nix and shell.nix

[aspauldingcode]

This repo is hard to clone and then use. Why? Firstly: ssh. I have to have ssh set up. Then I gotta use a browser, ssh-keygen and add a key to the github settings, so I can simply clone the repo to ~/.dotfiles

Secondly: how tf do I rebuild from there? I seem to always forget. It's always been so long so I can never really remember the right way to run the whole setup and rebuild from there.

Creating a shell.nix will solve this. If I can tell the shell to do the right steps on a new system, I can automate this confusingly difficult task of building the repo on a new machine.

In addition, I might even find a way to download my dotfiles which doesn't require ssh or xfce4/firefox to get up and running.

I'll need to make it work on my linux machines and my darwin machines.

[aspauldingcode]

Breaking it down:

@gekoke:envs.net says:

• SSH isn't required for HTTPS clone.
  1. You can clone the repo over the internet using Git and document any steps you need to take in plaintext.
  2. Build a custom ISO that includes the flake itself so you can even use it offline (you can even add any helpful scripts or automation here too). You do have to make sure that you have the latest ISO built whenever you set up a new host with this method.

---

Another thing:

• You can encrypt all secrets in your repo and decrypt all of them at runtime, but you still need to provide that one key to decrypt those secrets yourself.
• Nix-compatible secret management tools don't work that way as far as I know.

---

To rebuild from scratch:

• Just use:

  nixos-rebuild switch --use-remote-sudo --flake yourflake#yourDesiredNixosConfiguration

• If your live environment is flake-enabled:
  • (If not, it's just a few more flags)
  • Use:

    --extra-experimental-options "flakes nix-command"

[aspauldingcode]

you can even have this partition your drives if you're determined enough could use diskos or something

[aspauldingcode]

you can even have this partition your drives if you're determined enough could use diskos or something

actually it's nixos-install but it should accept the --flake flag

[gekoke]

You can encrypt all secrets in your repo and decrypt all of them at runtime, but you still need to provide that one key to decrypt those secrets yourself.

Nix-compatible secret management tools don't work that way as far as I know.

Actually, they (primarily referring to agenix and sops-nix) work exactly like this. I said the 2nd point in this context:

<@gekoke:envs.net> you *can* encrypt all secrets in your repo and decrypt all of them at runtime, but you still need to provide that one key to decrypt those secrets yourself

you: could this be one time?

That is, these secret management systems require you to provide the key every time you rebuild the system.

[aspauldingcode]

That is, these secret management systems require you to provide the key every time you rebuild the system.

could this be provided with a hardware key? like a unikey usb or similar, and could it be the same key?

[gekoke]

You can read the documentation, but afaik they are fairly set in stone about what form of authentication they accept. Mostly they support asymmetric crypto like GPG and age keys. I'm not sure about the capabilities of hardware keys for encryption.

Yes, you can always use the same key - whether that's a good idea is up to you.

[gekoke]

I'll propose three possible strategies:

1) just carry around one private key on a USB stick and use that to decrypt everything on every host.

If you want, you can even encrypt the filesystem on this USB with a password so it can't be read in transit (can still be read on the host after decryption, of course).

pros: simple, works offline, works on all hosts all the time cons: key can be read in transit unless you encrypt with password, key becomes exposed to hosts you don't necessarily trust

2) generate a new key on every host, and rekey your secrets using the newly generated public key on an existing host

pros: safest, each host can only decrypt secrets you permit for that host cons: complicated, host can't access secrets before you rekey them on an existing host, have to transmit public key to rekey on existing host

3) use a hosted password manager to pull your private key on each host

pros: probably easiest, don't have to manage or transmit key yourself cons: doesn't work offline, dependent on third party, some level of trust required

Choose the strategy that aligns with your desired level of convenience and operational security, or come up with your own strategy.

[aspauldingcode]

do you think creating a universal iso is possible/worth it?

It would need to support: UEFI apple sillicon - with nixos-apple-sillicon (aarch64-linux) Nixos desktop regular (x86_64-linux and aarch64-linux)

I have many different devices this repo builds for, would it be able to boot iso for any of them?

[gekoke]

I have no clue how the Darwin side of things works, unfortunately.