subsequent run keeps stale/wrong github token in `/ect/nix.conf`

[bddap]

An edge-case shows itself when nix-installer-action is run twice. It can happen in ci setups that don't create ephemeral environments (think self-hosted gh runners).

The first run works as designed (including adding access-tokens = github.com=*** to /ect/nix.conf via NIX_INSTALLER_EXTRA_CONF). For the second run, the installer is skipped, so /ect/nix.conf keeps the token from the original run.

The token leaks from one workflow to another.

Security-wise, this is arguably not the responsibility of nix-installer-action; if the user needs isolation between subsequent actions they should be using ephemeral environments.

Still, the subsequent action does see the wrong github token. This would result in unexpected behavior:

• the second token might grant access to the wrong set of resources
• after a while, the token will expire and builds pulling from github will fail (http 401)

Potential Solution 1.

Don't write the token to /ect/nix.conf, add it to the NIX_CONFIG environment variable instead. (pardon my inconsistent psuedo-code)

NIX_CONFIG = NIX_CONFIG + "\n" + "access-tokens =  github.com=***" + "\n"
for line in NIX_CONFIG.split("\n") {
    # https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#multiline-strings
    assert line != "EOF"
}
{
    echo 'NIX_CONFIG<<EOF'
    echo "$NIX_CONFIG"
    echo 'EOF'
} >> "$GITHUB_ENV"