Private Dependencies requiring Credential Authorisation - a discussion

[CMCDragonkai]

There's quite a bit of discussion and history and solutions with regards to this problem.

But generally I want to reiterate, the problem is that there are dependencies that reside on remote URIs that require some kind of credential to access. It could be SSH-based, it could be API key based, or just HTTP basic auth, AWS S3 auth... etc. There are many kinds.

The most common form of this problem is dealing with private Git repositories. Thus Git repositories that require SSH authentication. And Nix 2.0 has builtins.fetchGit which as a workflow is much better than pkgs.fetchgitPrivate (and also different from pkgs.fetchgit). The main reason it works is because it runs at evaluation time, not at build time. This means it is able to run as my own user not nixbld*, thus acquiring the ambient authority of my user, and also because it's not running in the build sandbox caused by nix.useSandbox = true;. If either of these is true it would not work because either it doesn't have the ambient authority to read ~/.ssh, or that it doesn't even have a filesystem path to reach ~/.ssh. This is great... for Git.

I think we need a more general solution that works any scenario (so we don't special case Git here). And in some cases, we do need it to work during build time and not evaluation time.

It would be better to consider these credentials to be a sort of "capability"/authority to perform a task. To ensure the principle of least privilege, only the minimum credential that is required and the minimum "time" to access that credential that is required should be supplied to the nixbld* build phase. To be able to achieve this least privilege principle, is it only possible to deal with this at evaluation time? Is there a design/architecture that would also work for build time?

I imagined that if there was a way to pass a parameter into the nix-build without having that parameter be saved in the /nix/store, it would violate the reproducibility of the system. Basically rebuilding the same derivation would fail. So in order to keep reproducibility, one needs to be able to encode that capability into that derivation, but in such a way so that encoded credential cannot be used for other nefarious purposes.

I realise this may have some overlap with the private nix store secret problem.

• Provide options for storing secrets outside the Nix store #24288
• Support private files in the Nix store nix#8

Hopefully here (or potentially another issue if I missed one) we can discuss more general solution design to this problem.

[FRidh]

I'm closing this because this is a Nix issue and there is an RFC (WIP) for this.
NixOS/rfcs#5

[CMCDragonkai]

That RFC appears to deal with how to actually store secrets in Nix, but doesn't address how these will be utilised by all the various fetch functionality along with preventing the need to special case every kins of authenticated fetching. Also whether a build can be paused by asking for elevated permissions similar to polkit.