Leaving this as status:requirements because I think more details/planning are required first

Ideally in the config we'd be able to specify an SSH private key as the value to gitPrivateKey

We'd then need an additional attribute gitPrivateKeyType which could be either ssh or gpg, defaulting to gpg to maintain existing capability/be a non-breaking change.. Alternatively this could be inferred from the value itself potentially.

As with existing gpg signing functionality, we'd then git config the user.signingkey and commit.gpgsign attributes alongside the gpg.format attribute to ssh or gpg.

That should be all that is required, so I guess the big question is whether to explicitly state the key type or whether to automagically infer it.

For ssh keys we wouldn't need to do

and we'd need to add an addition to set gpg.format

If we can infer the key type, let's do that instead or requiring the user to specify it.

GitLab have merged changes to show Verified/Unverified on ssh key signing now alongside the provisioning of keys as Auth, Sign, or Auth and Sign.

FYI, I use renovate with signed commit & SSH.

I just mounted the required gitconfig file and ssh keys where they are expected, and it just worked.

https://gitlab.com/davinkevin.fr/home-server/-/tree/main/renovate/overlays/k8s-server?ref_type=heads

And verified in GitLab UI:

I haven't implemented it directly in reno as we've moved over to ephemeral keys using gitsign with sigstore backed off an internal pki.

There seems to be a quirk with SSH-based signing. GPG-based signing requires one file, and technically SSH-based signing also needs only one file (the private SSH key), but ssh-keygen -Y sign ..., which gets called by git commit -S ... under the hood, currently requires also the public SSH key. So, with a naive implementation, Renovate would need both the private and public SSH keys for SSH-based commit signing (see a workaround at the very bottom).

This is a reproduction of the problem, which I ran in an interactive ghcr.io/renovatebot/renovate container in a temporary directory:

# Create a new SSH keypair without a passphrase
$ ssh-keygen -t ed25519 -C "renovate" -N "" -f /tmp/id_renovate
Generating public/private ed25519 key pair.
Your identification has been saved in /tmp/id_renovate
Your public key has been saved in /tmp/id_renovate.pub
The key fingerprint is:
...

# Delete the public key
$ rm /tmp/id_renovate.pub

# Restrict access permissions for the private key
$ chmod 400 /tmp/id_renovate

# Create a test repository and enable SSH-based commit signing
$ mkdir /tmp/test-repository
$ cd /tmp/test-repository
$ git init
$ git config user.name renovate
$ git config user.email [email protected]
$ git config commit.gpgsign true
$ git config gpg.format ssh
$ git config user.signingkey /tmp/id_renovate

# Add a test file and commit it
$ touch test.txt
$ git add .
$ GIT_TRACE=1 git commit -m "init"
07:45:27.414752 git.c:465               trace: built-in: git commit -m init
07:45:27.415631 run-command.c:657       trace: run_command: ssh-keygen -Y sign -n git -f /tmp/id_renovate /tmp/.git_signing_buffer_tmpeSEfAe
error: Couldn't load public key /tmp/id_renovate: No such file or directory?

fatal: failed to write commit object

The same command sequence – without deleting the public key – passes successfully.

I've submitted a PR to address this unnecessary constraint: openssh/openssh-portable#499

As a workaround, we can generate the public SSH key from the private SSH key just to satisfy ssh-keygen -Y sign ...:

ssh-keygen -y -f <private_key_file> > <public_key_file>

Thanks for the research. The public key will be different each time it's generated, right? Will that be ok? Ie it doesn't need to match the public key on the git host. Or is it deterministic and rhetorical same every time?

No, the public key is always the same for a given private key.

Maybe Renovate could generate the public key once only too, if your request to the upstream lib is not addressed quickly

Do you mean once per run in contrast to once per project that Renovate updates?

Yes

Ah, yes, that's definitely an easy optimization.

🎉 This issue has been resolved in version 38.46.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 38.46.0

Your semantic-release bot 📦🚀