-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SSH based commit and push signing #18197
Comments
Leaving this as |
Ideally in the config we'd be able to specify an SSH private key as the value to We'd then need an additional attribute As with existing gpg signing functionality, we'd then 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 renovate/lib/util/git/private-key.ts Line 45 in 66f35c9
and we'd need to add an addition to set renovate/lib/util/git/private-key.ts Line 59 in 66f35c9
|
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
|
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 This is a reproduction of the problem, which I ran in an interactive # 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 renovate@example.com
$ 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 -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: Your semantic-release bot 📦🚀 |
What would you like Renovate to be able to do?
Add support for ssh based commit and push signing
If you have any ideas on how this should be implemented, please tell us here.
Pretty much the same way as the existing gnupg signing, but with ssh instead
Is this a feature you are interested in implementing yourself?
Maybe
The text was updated successfully, but these errors were encountered: