[Feature] Allow GPG signing on cz bump for tags and commits #347

Activity

1. rimelore

   added

   type: featureA new enhacement proposalA new enhacement proposal

   on Feb 16, 2021
2. woile commented on Mar 5, 2021

   

   woile

   on Mar 5, 2021

   Member

   More actions

   I'm haven't use -S so I'm not sure I can implement this. Don't you have to create a pair of keys to sign the commits? How would you configure this in a CI?

   If you could provide a mini-tutorial/explanation on how to do on a CI I'll give it a try. Otherwise we won't be able to support our users.

   Thanks!

   👍React with 👍2Reacted by Wei Lee and Kyle King
3. Lee-W

   added

   help wanted

   on Sep 26, 2021
4. Lee-W commented on Aug 20, 2022

   

   Lee-W

   on Aug 20, 2022

   Member

   More actions

   I think this has been supported since https://github.com/commitizen-tools/commitizen/blob/master/CHANGELOG.md#v2290-2022-07-22. Could you please try with version higher than v2.29.0? I'll close this one for now. Feel free to reopen it if you think there's something missed
5. Lee-W

   closed this as completedon Aug 20, 2022
6. samupl commented on Mar 20, 2023

   

   samupl

   on Mar 20, 2023

   More actions

   @Lee-W I believe this might still be unsupported - especially if somebody wants to explicitly sign commits, and not have git configured for auto-signing.
7. Lee-W

   reopened this on Apr 5, 2023
8. AdrianDC commented on Aug 22, 2024

   

   AdrianDC

   on Aug 22, 2024

   Contributor

   More actions

   I'd like to add always_signgpg and -S parameter to -- -S just as implemented in #1206,
   given this is common usage for developers and would allow better adoption
   (or default control for always_* as done currently using the MR changes).

   Tested manually in a clean Docker container using GPG local keys, and Git not configured for auto-signing :

   (I also have a physical Yubikey for hardware GPG but not testing it here, I might if facing a use case)

   # Create keys (defaults, with password)
   gpg --full-generate-key
   gpg --list-secret-keys --keyid-format=long
   
   # Signing key: sec   .../BC48BD5325580A88 ...
   # Signature key: ssb   .../2785C6F3562417C5 ...
   
   # Configure Git user
   git config --global user.signingkey BC48BD5325580A88
   git config --global --get user.signingkey
   
   # Configure GPG
   cat >>~/.gnupg/gpg.conf <<EOF
   use-agent
   pinentry-mode loopback
   EOF
   cat >>~/.gnupg/gpg-agent.conf <<EOF
   allow-loopback-pinentry
   EOF
   
   # Configure hooks
   export SKIP='no-commit-to-branch'
   
   # Create Git commit with GPG (Enter passphrase: should ask for GPG passphrase)
   git add -p ./...
   git commit -S
   
   # Validate signature (should show in blue under commit SHA)
   git log --show-signature
   
   # Create commitizen commit with GPG
   git add -p ./...
   cz c -- -S
   
   # Validate signature (should show in blue under commit SHA)
   git log --show-signature
9. nbehrnd commented on Oct 22, 2025

   

   nbehrnd

   on Oct 22, 2025

   Contributor

   More actions

   Observation: With contemporary git (e.g., version 2.50.1 as packaged for Debian 14/forky) it is possible to run

   git config --global commit.gpgSign true

   to then add to file ~/.gitconfig the entry

   [commit]
   	gpgSign = true
   

   -- regardless if the signature is with a keypair of GPG, or ssh. This helps me to sign a commit, or tag which for some reason requires once -S, the other by -s. However this is incompatible with commitizen version 4.9.1 fetched from PyPI; cz c eventually yields

   ...
   error: ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory?
   Load key "/home/USERNAME/.ssh/dedicated_ssh_key": incorrect passphrase supplied to decrypt private key?
   
   fatal: failed to write commit object

   Current bypass: A manual edit of file ~/.gitconfig to set gpgSign = false; subsequent use of commitizen by cz c with an additional git commit --amend -S.

   Question: Could future versions of commitizen allow to enter the passphrase protecting the ssh keypair?