feat: adding support for GPG signing via sequoia-pgp with additional …

[sikula]

This PR is building off of #219 to successfully add PGP signing of git commits via the sequoia_pgp library. Git commits successfully show up as signed via git log --show-signature

To sign commits, follow the below steps:

Configuring

Export Private Key
gpg --export-secret-keys YOUR_KEY_ID > ~/.keys/git.pgp
chmod 600 ~/.keys/git.pgp

Add Key Path To Git Config
git config --add gitui.keypath ~/,keys/git.pgp

Then use gitui to create a commit, your commits will be automatically signed.

Caveats

Doesn't support encrypted keys
Currently encrypted keys are not supported, only passwordless keys, which mainly has to do with the interface between gitui and asyncgit, as the signing logic happens on the asyncgit side while the ui stuff happens on the gitui side.

Supporting encrypted keys would require creating a SignComponent similar to the CredsComponent (hiding passwords is already supported for credentials so not a lot of additional work would be required to make that work), and checking whether a key needs to be decrypted and showing the SignComponent dialog box to enter the password and then sending that down to asyncgit to create the signature.

Adding additional git config parameter
I don't see this as a negative, it's fairly straightforward to export the secret key and update the git configuration to specify the key path, this actually makes gitui more flexible as it doesn't need gpg to run, but rather a pgp spec adhering key.

Secret keys can be treated similar to ssh keys (chmod 600)

Additional Work

Verifying Signature
Although git signatures will show up verified with git log --show-signature, there is no indication in gitui that commits have been verified, so something similar to git log --show-signature or (https://git-scm.com/docs/pretty-formats#Documentation/pretty-formats.txt-emGem) would be helpful.

[sikula]

@extrawurst Let me know your thoughts :)

[extrawurst]

@sikula thanks for looking into this. is there any way we can fix the failing CI?

[sikula]

@extrawurst I would say so, most of the issues are because sequoia-pgp requires an extra package for the cryptography layer called nettle, so as long as you are ok with an extra package that needs to be installed.

[blaggacao]

Just want to say how desperately I'd need this. Not desperately enough though to hijack this PR 😄

I hope you can lift this over the final hurdle for merge.

[sikula]

@blaggacao I haven't been able to find the time to fix the checks, however I built gitui from my branch and have been using it for signed commits at work.

[weihanglo]

Hey @sikula. If you don't have time working on this, would you mind me pushing this forward based on this PR?

[extrawurst]

@weihanglo that would be great

[sikula]

@weihanglo 100% be my guest, I think this is a very requested feature that would be very valuable to have merged.

[mainrs]

There are a bunch of other PRs already open that add signing:

• Support commit signing with gpgme #817, depends on gpgme and I think we should stick to sequioa. should be superseeded by this PR.
• Add support for GPG signing commits #219, abandoned. should be closed.

I think the draft should be implemented completely with support for encrypted keys. If someone would like to guide me on how (in the sense of how do I pass down the password to asyncgit) and where to add it, I can do that.

[blaggacao]

If someone would like to guide me on how (in the sense of how do I pass down the password to asyncgit) and where to add it, I can do that.

I'm not 100% proficient on the topic, but it appears to me as if something would already shell out to the available pinentry for just that (Maybe git? Maybe gpg?). If that's the case, then that would mean that no special precautions at all would have to be taken.

[mainrs]

If someone would like to guide me on how (in the sense of how do I pass down the password to asyncgit) and where to add it, I can do that.

I'm not 100% proficient on the topic, but it appears to me as if something would already shell out to the available pinentry for just that (Maybe git? Maybe gpg?). If that's the case, then that would mean that no special precautions at all would have to be taken.

Wouldn't that mess with the UI though?

[sikula]

@mainrs I can provide a few resources that might help you with this. I would start with looking at the sq (sequoia-pgp cli), specifically here (for signing) and here (for decryption).

I would then look at this part of the gitui project to understand the UI component and how to show editor boxes/accept input.

And finally, here in asyncgit, we call the create_signature function which would be modified to accept a password.

[sikula]

@mainrs the only other thing might be how to make the input characters not visible or replace them with * so the password isn't visible when you type, but maybe @extrawurst can chime in on how to make that happen.

[balsoft]

Adding additional git config parameter

I don't see this as a negative, it's fairly straightforward to export the secret key and update the git configuration to specify the key path, this actually makes gitui more flexible as it doesn't need gpg to run, but rather a pgp spec adhering key.

This means it's impossible to use gpg-agent or sign with smartcards, right?

What are the disadvantages of "needing gpg to run"? I feel like it would solve all the aforementioned issues, integrate into people's existing workflows much better, and be simpler to implement as well.

[stale]

This issue has been automatically marked as stale because it has not had any activity half a year. It will be closed in 14 days if no further activity occurs. Thank you for your contributions.