search

iomentum / cargo-scaffold

cargo scaffold lets you scaffold and generate projects described in a simple TOML file
MIT License
56 stars 12 forks source link

Scaffold cloning mechanism not respecting git ssh configuration #30

Open abernix opened 2 years ago

abernix commented 2 years ago

My authentication with GitHub is done with SSH keys (rather than https://) and I use a Yubikey to provide my SSH keys. I assure you that my git commands work properly. 😉

To ensure I use git+ssh rather than https:// for cloning things, I have the following in my ~/.gitconfig:

[url "git@github.com:"]
  insteadOf = https://github.com/

So, proving my git works:

$ git clone https://github.com/apollographql/router.git
Cloning into 'router'...
remote: Enumerating objects: 20071, done.
remote: Counting objects: 100% (110/110), done.
remote: Compressing objects: 100% (72/72), done.
remote: Total 20071 (delta 66), reused 61 (delta 38), pack-reused 19961
Receiving objects: 100% (20071/20071), 7.17 MiB | 6.66 MiB/s, done.
Resolving deltas: 100% (14418/14418), done.

However, when I try this with cargo-scaffold using the https:// URL, I receive:

$ cargo-scaffold scaffold https://github.com/apollographql/router.git -r apollo-router-scaffold/templates/base
🔄 Cloning repository…
Error: authentication required but no callback set; class=Ssh (23); code=Auth (-16)

... and with the git+ssh approach:

$ cargo-scaffold scaffold git@github.com:apollographql/router.git -r apollo-router-scaffold/templates/base
🔄 Cloning repository…
Error: Failed to authenticate SSH session: Unable to extract public key from private key file: Unable to open private key file; class=Ssh (23)

Ultimately, I think this comes down to the same challenge that cargo ran into by trying to use an underlying git library that wasn't a full implementation of the git CLI's abilities — for example, the CARGO_NET_GIT_FETCH_WITH_CLI env variable and its corresponding setting. (For what it's worth, I tried using that env variable, but it didn't help, though I'm not surprised since that's cargo-specific behavior).

Those limitations are explained a bit in https://github.com/rust-lang/cargo/blob/9ded34a558a900563b0acf3730e223c649cf859d/src/cargo/sources/git/utils.rs#L816-L905 where you can see how they work around it.

de-vri-es commented 1 year ago

This could maybe partially be fixed by #40, which adds more authentication mechanisms, including using the ssh agent and more default keys in addition to ~/.ssh/id_rsa.

I'm not sure about the insteadOf. That sounds like libgit2 simply doesn't implement it, so using auth-git2 would not solve that.