Sign git commits with SSH keys

[skyfaller]

Is your feature request related to a problem? Please describe.
I would like to be able to sign git commits with SSH keys from gitui.

• https://blog.dbrgn.ch/2021/11/16/git-ssh-signatures/
• https://calebhearth.com/sign-git-with-ssh
• https://lobste.rs/s/l5h2ct/git_ssh_signing_add_commit_tag_signing

This is a new feature that seems to only work properly with OpenSSH 8.8 and above, which can make it challenging to test on more stable OSes; but if you are able to use it, it seems painless compared to GPG. Because it is new, it also has poor support on GitHub and other code forges, but I expect that will change.

It may also seem premature to consider, given that GPG signing isn't supported in gitui yet; on the other hand, now may be a good time to consider the user interface to make it easy to support signing with SSH keys as well as GPG keys in the future.

[skyfaller]

GitHub now supports verifying commits using SSH keys: https://github.blog/changelog/2022-08-23-ssh-commit-verification-now-supported/

[extrawurst]

this feature needs to be supported by upstream libgit2 first

[dnaka91]

I did try to implement GPG signing in the past as part of #97, and it turned out to be very difficult, due to not having a native Rust crate for the GPG part. Basically, it complicated builds on Windows due to some extra C dependencies and licensing might be problematic too.

So I recently tried out to implement SSH signing instead, as I discovered the relatively new ssh-key crate from the RustCrypto group. After a little forth and back with them, they added an implementation for SSH signing to it, and with the current 0.5.0-rc.0, it's very easy to sign commits.

The workflow is exactly the same as with GPG signing, so we wouldn't have to wait for libgit2 to integrate that.

Here is a very minimal example:

# Cargo.toml

[package]
name = "gitsign"
version = "0.1.0"
edition = "2021"

[dependencies]
anyhow = "1.0.66"
dirs = "4.0.0"
git2 = "0.15.0"
ssh-key = { version = "0.5.0-rc.0", features = ["ed25519", "encryption"] }

// src/main.rs

use std::{env, fs};

use anyhow::Result;
use git2::Repository;
use ssh_key::{HashAlg, LineEnding, PrivateKey};

fn main() -> Result<()> {
    // Create a new repo at ./tmp
    let dir = env::current_dir()?.join("tmp");
    fs::remove_dir_all(&dir).ok();
    fs::create_dir_all(&dir)?;

    let repo = Repository::init(&dir)?;

    // Prepare an empty commit
    let mut index = repo.index()?;
    let tree = index.write_tree()?;
    let tree = repo.find_tree(tree)?;

    let signature = repo.signature()?;

    let content = repo.commit_create_buffer(&signature, &signature, "Initial commit", &tree, &[])?;
    let content = String::from_utf8(content.to_vec())?;

    // Sign with SSH key
    let ssh_dir = dirs::home_dir().unwrap().join(".ssh");

    let key = fs::read(ssh_dir.join("id_ed25519"))?;
    let key = PrivateKey::from_openssh(key)?.decrypt("<YOUR PRIVATE KEY PASSWORD>")?;

    let sig = key
        .sign("git", HashAlg::Sha256, content.as_bytes())?
        .to_pem(LineEnding::default())?;

    // Perform actual commit
    let commit = repo.commit_signed(&content, &sig, None)?;
    let commit = repo.find_commit(commit)?;
    repo.branch("main", &commit, true)?;

    Ok(())
}

After running it, you can go to the ./tmp folder and verify the signature with git log --show-signature.

@extrawurst with that, what do you think about implementing SSH signing first, before continuing on the GPG signing path, which seems rather stuck?

There is just one problem: Getting the private key. The Git configuration allows different ways of specifying the key. It can be:

• A public key handle, which means Git will talk with the SSH agent (through ssh-keygen which does all the signing). This seems the most preferred setup.
• Direct path to the private key. This one we could support as a first implementation.
• A program which will respond with the public key handle to use, and then Git will talk to the SSH agent.
• No key config at all, which means it'll interactively ask for the right handle or pick the first key returned by the SSH agent (based on the config).

Given all these possible options, it might even be easier to just do the same as Git and shell out to ssh-keygen instead of natively implementing it 🤔

[extrawurst]

what do you think about implementing SSH signing first

absolutely welcome. and as usual I am for implementing the first version (MVP) of it as simple as possible and then iterate over it. so I assume a direct path to the key to be used via program param would be the way to go. after that we should look into querying the agent and only afterwards go for the most complicated version where we need to have a UI for the user to choose from key options.

[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.

[matthiasbeyer]

Still relevant.

[extrawurst]

libgit2/libgit2#6617 - soon supported by upstream

[extrawurst]

Also really interesting read about another tool using libgit2-only without shellout to support ssh signing: https://blog.gitbutler.com/signing-commits-in-git-explained/

[SaadiSave]

libgit2/libgit2#6617 - soon supported by upstream

Since this is now supported upstream in libgit2, will gitui automatically respect the commit.gpgsign config option for SSH signing?