Abstract Nix Config Iface

[blaggacao]

Problem Statement

As a CI action, it provides nix in the context of CI.

However nix (currently) is notoriously quirky to configure.

For example:

• only new commands read self.nixConfig
  • but old style commands may be still inevitable for a while
• some config doesn't play well with old style commands and produce errors (iirc. accept-flake-config !?)
• there is also NiX_CONFIG and ~/.config/nix.conf and also /etc/nix/nix.conf
• to make matters worse they are a custom ini format (with lists as spaced separated strings)

In CI, though, we actually only care that my intended (pretty much single) configuration is observed in all (edge) cases.

Often times, in fact, we may find ourselves debugging nix config during CI development.

Potential Solution

As a provider of a CI nix, this action could implement a config interface inputs.config that transforms / merges / (and even special cases) the config so that the user intent is preserved.

I haven't checked if this is legal, but if so, it would be nice:

inputs:
  nixConfig: ${{ fromJSON(my-json-obj) }}

Or alteratively

inputs:
  nixConfig:
    substituters:
      - ...

[blaggacao]

@nrdxp NixOS/nix#7560 ?

[nrdxp]

Looks like github only accepts strings as action input, so if you wanna do this we would have to pass the json raw and parse it in the action.

As far as the implementation, I think the environment via NIX_CONFIG would be ideal, so that sensitive settings like access-keys never have to hit the disk, but as you link above, we'd have to resolve that issue first so extra- settings can be merged with the defaults. If we could do that, the only "on disk" secret left would be the value of secret-key-files: NixOS/nix#7564.

The "nix.conf" format is simple enough that it might not be too difficult to teach Nix to just read its config from straight JSON as well.

I think both of the linked issues are simple enough that I may be able to resolve them myself, as I've gotten a little more familiar with the Nix codebase recently.

[blaggacao]

I have been tought, secrets should be on disk and not in the environment, as this is more secure.

• The file ACL is enforced on every access.
• Environment variables are already preaccessed, potentially by a parent process with more privileges.
• You can (atomically) hot swap a secret by file, but not by environment.

Just wanted to clarify if we're having had different schools on this questions.

---

If nix was to ingest json directly, for the value proposition of this issue, we'd have a little less work to do, indeed.

We'd still likely have to adjust the json for the new and old commands as not all flags seem portable between the two.

[nrdxp]

Well if the CI runner is compromised, attackers can likely get the secrets either way. I guess it just depends on what you are optimizing for (threat model).