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

[ShaneMalachow]

Description

Allow for the version tag and commit from a cz bump command to be signed using a GPG key.

Possible Solution

Implementing a flag on cz bump that allows for the tag and commit to be signed by adding the -S argument to the git client.

Additional context

This is related to issue #248 but the fixes proposed to cz c there won't help if I also need to enforce tags and commits during a version bump being signed.

[woile]

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!

[Lee-W]

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

[samupl]

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

[AdrianDC]

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

[nbehrnd]

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?