search

drewdeponte / git-ps-rs

Official git-ps Rust implementation - the future of git-ps
https://git-ps.sh
MIT License
78 stars 8 forks source link

Don't require user.signingKey config #299

Open alondahari opened 4 months ago

alondahari commented 4 months ago

At my new job we use GitHub codespaces, which I've set up to sign my commits automatically. I use an SSH tunnel to connect to the codespace so I can keep using my beloved NeoVim.

It works great, but gps throws an error when it's trying to sign the commits, due to missing signingKey in my config. Looking at the docs, the signing key is not required for signing. I believe the credentials helper in the codespace takes care of that, since it's inside a trusted environment. I'm sure there are other such environments.

This currently prevents me from using gps completely unfortunately.

drewdeponte commented 4 months ago

I agree that we should match the behavior of Git proper with respect to this.

To do so I think we need to do the following.

  1. add support for automatically selecting the signing key (this logic exists in Git's code base somewhere)
  2. remove the returning an error when the config can't be found, and instead simply fall back to auto selection

From looking at gpg-interface.c in the Git code base it looks like they only fall back to this auto selection for SSH signing. I believe the implementation we would be looking for is the function named, get_default_ssh_signing_key. It is defined in gpg-interface.c.

drewdeponte commented 3 months ago

After digging into this a bit further it seems that either user.signingKey is required or gpg.ssh.defaultKeyCommand is required to be present.

@alondahari In your use case is gpg.ssh.defaultKeyCommand provided?

alondahari commented 3 months ago

I don't think it's using ssh signing. gpg.program is set, and there's a credential.helper set as well. Where are you looking? code or documentation?

using git v2.44.0

drewdeponte commented 3 months ago

I am referrencing the code and the documentation. I think it has to be using the signing key you provide otherwise it would be inconsistent outside the realm of the code space which would be all bad.

Looking explicitly at the code for v2.44.0, specifically the gpg-interface.c file they even have this line.

https://github.com/git/git/blob/v2.44.0/gpg-interface.c#L858

If you then look at the supported gpg_formats, https://github.com/git/git/blob/v2.44.0/gpg-interface.c#L89 , ssh is the only one that has a default key command. This also lines up with everything I have read in documentation.

So, it seems like for Git Patch Stack to match Git's behavior it should fallback to the command to get the default key for the case of ssh and only ssh.

But, that means in terms of your specific use case. We don't understand everything quite yet. Maybe there gpg.ssh.defaultKeyCommand is being defaulted in code somewhere that I missed prior to it being used and therefore you don't have to have it explicitly configured in your config and that is why you aren't seeing it in the config.

It is also possible that in code spaces they have other git configs that are merged together. If I remember correctly there is support for a local, global, and system level git config at .git/config, ~/.gitconfig, and /etc/gitconfig. The priority is local, then global, then system as well. So we really need to check all those configs.

alondahari commented 1 month ago

Sorry for taking a while to reply. If you take a look at the GH docs, you can see they are using in the codespaces a custom gpg binary. The binary is using a token set by the credentials helper, also referenced in the git config. It is not using the user.signingkey or defaultKeyCommand.

I believe I have the full picture regarding the configs applied since I list them with git config --list --show-origin, and I don't have any conflicting configs.

I believe the same method is used when you make an edit to a file using GitHub's web interface.

I agree that it seems like only SSH has the defaultKeyCommand fallback, but I don't think this is the relevant thing to look at. Are we utilising the configured credentials helper at all? could we run the GPG program without a signing key if it's not set and run the credentials helper?

I'm also confused about the flags we pass to the gpg signer, that don't match up to the ones passed in by git. What reference do you use for those flags?