GPG sign commits

[nbigaouette]

All my commits are required to be signed at work. It would be awesome to be able to commit directly in gitui; for now I can stage files/hunk and commit using git directly.

Thanks!

[extrawurst]

Hi @nbigaouette thanks for your interest in the project. I did not even know that feature existed 🙈. I am going to need support by someone having experience with using signing in git for this.

[extrawurst]

some docs on how git does gpg:

• https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work
• https://docs.github.com/en/github/authenticating-to-github/signing-commits

[extrawurst]

See https://github.com/rust-lang/git2-rs/issues/507

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[extrawurst]

@nils-a what do you mean? in fact someone is working on this issue

On Tue, Oct 27, 2020 at 11:03 PM Nils Andresen [email protected] wrote:

@extrawurst https://github.com/extrawurst does your Reference of that issue means that "someone" will simply need to implement the mentioned workaround?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/extrawurst/gitui/issues/97#issuecomment-717566761, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAF5U4HHRHH4VDIQ6CR6KRDSM47RVANCNFSM4NOI7FEQ .

[nils-a]

Yes. I saw that after I commented. Hence the deletion of the comment. Sorry for that. 😇

[extrawurst]

@nils-a But as you can see in the PR it is non trivial and could use some support, so if you want to chime in... so to your initial question: I posted references for people to pick up. as usual in open source: when you want something done - do it :)

[nils-a]

yes.. love to. Need to buy a book on rust first :-)

[extrawurst]

@nils-a that's an easy step - see you soon then :P

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[dnaka91]

Is anybody still working on this? For me this is currently a blocker as well because I usually sign all my commits.

I used gpgme with git2 in one of my projects before and could probably integrate this rather quick.

[nils-a]

Not me. I'm still reading that book on rust to begin with... But there is also some discussion in https://github.com/extrawurst/gitui/pull/219

[extrawurst]

@dnaka91 absolutely have a go at it

[dnaka91]

Sorry, I didn't have a chance to continue on this as I'm currently quite occupied with other things.

I definitely have this on my to-do list though.

[jakobkmar]

Shouldn't the following lines in the .gitconfig cause all commits to be signed regardless of the program doing the commit?

[user]
  name = YOUR_NAME
  email = YOUR_EMAIL
  signingkey = YOUR_SIGNING_KEY
[gpg]
  program = GPG_BINARY_PATH
[commit]
  gpgsign = true

Any ideas why that isn't the case and does not with gitui?

[extrawurst]

@bluefireoly gitui uses libgit2 a c++ implementation of git and not the git-cli. libgit2 does not do anything automagically and the necessary implementation was not done yet

[extrawurst]

@bluefireoly I added #740 - it should not even allow you to commit now iff you have this config defined. this way it prevents you from generating unsigned commits even though you expressed that you need them to be signed

[jakobkmar]

Alright thank you, maybe that will prevent some people from finding this out when it is too late.

[codebasu]

I came across this issue today as I was still on v0.15 and was surprised when it let me commit without signing even with config set.

Looking into it more, I came across this: https://libgit2.org/libgit2/#HEAD/group/commit/git_commit_create_with_signature

Not sure if this issue is on libgit2 or the git2-rs, so not sure if any help or not.

[extrawurst]

I came across this issue today as I was still on v0.15

this was part of 0.16 release: https://github.com/extrawurst/gitui/releases/tag/v0.16.0

[mcrakhman]

@extrawurst Hi! I guess we can try just calling gpg using Command::new("gpg"), pass the signature as a parameter like gpg --sign --default-key [SIGNATURE] and then pass the commit buffer inside stdin and get the signed data through stdout. Then we can probably just use commit_signed of git2-rs.

I will try to implement something like that on the next week, it can be a lot easier that trying to use heavy libs like sequoia.

[extrawurst]

I prefer we find a native solution (sequoia or gpgme). One design philosophy for gitui so far was to not rely on the git cli, I am not intending to change that as long as we did not exhaust all options

[dnaka91]

Sorry, I didn't update my progress on this in a long time. I have the changes working locally but don't know what to do about the amend function. That doesn't allow to sign again (which we have to as the commit contents change).

Therefore we would have to do the whole amend from scratch which takes time to implement. Basically it's more or less the same as a normal commit, just changing the state back to the previous commit first. But it's problematic as soon as something goes wrong and we have to make sure we don't lose any data in the process and restore the old state before trying the amend.

[extrawurst]

@dnaka91 would be great if you could put that into a PR draft 👍

[dnaka91]

Sure I'll open a draft PR later today. It's still quite messy and missing tests to cover the new code, but it's better to have some code as basis for further discussions 👍

[basbebe]

Has there been any progress on this?

[extrawurst]

@basbebe latest work happened in #817

[castarco]

Hi, is there any way I could help? Although in a completely different context, I had to add support to GPG signatures to one of my own projects ( https://avatar-cli.dev ), so maybe I could help here.

I did it the "dirty way" (by relying on the external git binary), but I guess it wouldn't be too complicated if I have to rely on a librarized version of it for this project.

EDIT: I see that there were at least 3 PRs focused on that, all of them stalled. So... maybe it is that complicated. My take on this is that maybe we should find a way to split this feature into smaller ones, if that's even possible, so we can go one small step at a time.

Also, for reference, I think that the last work on this topic actually belongs to this other PR: #910 , as #817 was closed.

[hendrikmaus]

@castarco indeed, this is not a trivial thing to implement. I'd like to second your idea of splitting the feature into multiple smaller parts; some could even be merged while hidden behind a feature toggle (can be as simple as a comment).

---

Before writing any code, I would propose to work on the following and sign each one off with @extrawurst:

1. Define the requirements
2. Evaluate technology to aid the implementation
3. Verbally express the implementation path(s)

---

The following are my partial proposals for discussion:

1) Define the requirements

• re-use existing configuration in a user's .gitconfig, i.e. user.signingKey
• integrate with the gpg agent, including:
• allowance for interactive pin-entry

2) Evaluate technology to aid the implementation

• @extrawurst already mentioned that only solutions leveraging either gpgme or sequoia will be accepted
• looking at the metric of open-source "stars", sequoia wins (gpgme 55, sequoia 306)
• gpgme is a crate that provides bindings to lower level dependencies, while sequoia is a complete re-implementation in Rust; I'd prefer sequoia
• sequoia has a positive testimonial from the creator of PGP, Phil Zimmermann
• both crates provide plenty of examples
• gpg-tui (~1 year old) uses gpgme

I'd propose to move forward with sequoia because of it being a Rust-native solution + being more popular.

3) Verbally express the implementation path(s)

To be honest, I did not yet dive into the codebase, because there are too many open questions. Once we have more decisions, it would be nice to get the folks back into the loop who have already submitted pr's. No matter if they abandoned them or not, their feedback and input is valuable nontheless.

[extrawurst]

hi @hendrikmaus and thanks for wrapping this up. this topic is long running and arguably one of the most requested features. I am glad you are going to approach this with such a thought out structure.

since I am not using commit signing myself, my opinion on this is rather high level. my biggest concern is cross-platform support and testability. we need to make sure we come up with something that works on all three platforms and is well covered in tests, so that A) I can us the tests as a life raft if I need to maintain the code after potential contributors sailed away and B) to guarantee stability on the platforms I am not using myself.

your points so far seem reasonable to me. I personally had no tendency for either gpgme or sequoia but I can follow your assessment!

I assume in terms of slicing this I would make a first iteration without support of interactive pin entry, because adding that should be easy, we do a similar thing already for https credential input on demand.