nix icon indicating copy to clipboard operation
nix copied to clipboard

`fetchGit` needs a way to specify identity

Open lostmsu opened this issue 1 year ago • 3 comments

Is your feature request related to a problem? Please describe. In my configuration.nix I reference a private GitHub repo. In order to access this repo git client needs to use specific identity file (e.g. ~/.ssh/special_id_ed25519) The problem is that there's no way to tell fetchGit where to find this file:

  • there's no option on fetchGit itself
  • setting programs.ssh.extraConfig does not work because fetchGit runs before ssh config is generated

Describe the solution you'd like fetchGit should have a way to specify identity file path or the identity itself

Describe alternatives you've considered N/A

Additional context N/A

Priorities

Add :+1: to issues you find important.

lostmsu avatar Jun 22 '24 18:06 lostmsu

Might passing the following environment variable work?

GIT_SSH_COMMAND="ssh -i ~/.ssh/special_id_ed25519"

roberth avatar Jun 25 '24 08:06 roberth

How can I pass an environment variable to fetchGit command in general case?

Suppose this fetchGit is called from my configuration.nix

lostmsu avatar Jun 25 '24 17:06 lostmsu

How can I pass an environment variable to fetchGit command in general case?

GIT_SSH_COMMAND affects all fetchGit invocations. For a fine grained solution it's best to use ssh_config, so that your expression isn't more environment-specific than necessary. For example, that way you could switch to using a keyring to unlock your key, or some other fancy solution without making your expression incompatible. This is especially important if you collaborate with others on a config. Hardcoding a path in the expression would prevent that.

In my opinion, configuration managers could be more helpful with the bootstrapping process, or maybe you could have a special $[name}-boot config for the first run? Both configs could import a module that defines your programs.ssh.extraConfig.

Providing an extra parameter to fetchGit is not my preferred solution because it adds complexity and competes with a more flexible option, but private repos are a real pain if something doesn't work well, so I'd consider a contribution that adds such a parameter nonetheless.

roberth avatar Jun 25 '24 18:06 roberth