Respect Git configuration related to signing when creating commits

[Byron]

Currently, GPG based signature configuration is not respected by default, even though users would expect commits to be created just like Git would.

For instance, creating a commit in a virtual branch and pushing that will cause the commit to be unsigned, even if the user configured commit signatures, i.e.:

[user]
  name = User
  email = [email protected]
  signingkey = 4D90A8D52B4321F7
[commit]
  gpgsign = true

Right now there is an option (default off) to sign with a locally generated key…

…but using that wouldn't imply that it is trusted by other parties.

Sources of Confusion

• The "Use Git executable" authentication method actually affects how to fetch and push, with auth* being implied. Users may think that this rather means to use Git for all (or most) operations so that their settings would be respected no matter what.

Related Issues

• Commits, that have been amended, are not signed with user signature #3449
• rebased commits are not re-signed #3147
• feat: allow signing rebased commits #3243

[jrushlow]

Just some constructive feedback: the inability to sign commits based on my existing git config is a blocker for me. I can see a huge benefit in using GitButler while maintaining say symfony/maker-bundle || symfony/symfony - a repo in which I jump around between branches alot. But, my development flow is complicated enough, I do not want to have to add another "piece to the puzzle" in order to use additional tooling. E.g. maintain another gpg key for signing commits when I already have a perfectly good one.

Anywho - Look forward to seeing GitButler grow, and hopefully being able to use it in my day to day in the near future...

[MikeJCusack]

The initial comment mentions about GPG based signing, but for me I would like to have my keys in 1Password be used for signing, as is the case without using GitButler. Using GitButler's key is usable by adding that key to Github/Gitlab, but it would be nice to be able to use 1Password keys for both authentication and signing.

[jrushlow]

@MikeJCusack I could be wrong, but I believe that when this issue gets implemented, that would work out of the box for you -assuming that when you do a git commit on the CLI, your commit is signed as expected.

It's my understanding that when your .gitconfig commit.gpgsign: true - under the hood git will use the key set in user.signingkey else fall back to gpg defaults.

I wouldn't be surprised if the 1password cli tool ultimately imports the gpg key into your local gpg keyring to make things appear seamless on the os level. e.g. 1password is not replacing your local gpg as a signing agent / key store

[MikeJCusack]

I'm using ssh commit signing, but otherwise this is my understanding as well. Just wanted to make sure this fix would be addressing both gpg and ssh signing.

You can save GPG keys in 1Password since you can save any type of file as an attachment, but for developers it just provides an SSH agent to handle secure storage and access of ssh keys. It saves a copy of the public key in ~/.ssh, but no security issue there since it's public. There isn't any GPG functionality.

[Qix-]

Yes this is a known issue, I've been meaning to add signing support to the fork/exec end of things. Assuming I can get rust-analyzer working again in gitbutler-core I'll address this within the week.

The problem is indeed the confusing bit about which "auth method" you use - it doesn't change which implementation of Git we use for all operations, just for push/pull at the moment. This means that libgit2 is still used to handle the commit/sign process, but we'd like to extend the support for System Executable to also do the final commit-tree call when it's selected as the auth mechanism, too - which will indeed solve pretty much any signing concerns you'd have.

I just need to make sure it works with our ASKPASS implementation so that e.g. passphrase prompts properly forward to the client.

FWIW this also blocks me from using GitButler at the moment, so it's rather high priority for me as well :)

[Byron]

I think this may also be fixed by now.