Git: Signing stopped working in Git 2.9.3

[pdolezal]

• [x] I was not able to find an open
  or closed issue
  matching what I'm seeing

  Setup

• Which version of Git for Windows are you using? 32-bit or 64-bit? Include the
  output of git version as well.

Tried 2.9.0.windows.1, 2.9.2.windows.1, 2.9.3.windows.3 and 2.10.0.windows.1, all 64-bit. The problem spotted in 2.9.3.windows.3 and still present in 2.10.0.windows.1.

$ git --version
git version 2.9.3.windows.3

• Which version of Windows are you running? 32-bit or 64-bit?

Windows 7 Ultimate 64-bit

• What options did you set as part of the installation? Or did you choose the
  defaults?

Defaults.

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

All worked before, the problem appeared after upgrading Git from 2.9.0.windows.1 to 2.9.3.windows.3. Anyway, gpg --list-key works and provides the expected list of keys, user.signingkey is set as before the upgrade – no change besides the Git upgrade happened. After downgrading back to 2.9.0.windows.1, the signing started to work again.

To verify that the upgrade was responsible for the problem, I used a clean system installation (Windows 7 Ultimate, 64-bit) in a virtual machine, equipped it with the same GPG keys, installed Git 2.9.3.windows.3 and tried the signing as described in details with the negative result. When downgraded the installation to 2.9.0.windows.1 or 2.9.2.windows.1, signing started to work. Upgrading to any newer version (2.9.3.windows.3 or 2.10.0.windows.1) broke the signing.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

Bash.

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git init
git commit ---allow-empty -m "Test"
git tag -s test -m "Test"

• What did you expect to occur after running these commands?

Tagging should ask for the key passphrase and succeed after providing the correct password. The newly created tag should be signed then.

• What actually happened instead?

$ git tag -s test -m "Test"
error: gpg failed to sign the data
error: unable to sign the tag

The tag was not created at all, no more details about the error were provided.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

A new repository was used.

[jibsen]

Just ran into the same issue, Win10 64-bit using 2.10.0.windows.1.

Edit: I can see some changes regarding GPG signing in the Git 2.10 release notes, perhaps that broke compatibility with GPG on Windows.

[dscho]

Could you install the Git for Windows SDK and verify that cd /usr/src/git/t && sh t4202*.sh fails? Because if it does not fail for you, then the regression test suite managed to sign a tag...

[pdolezal]

I tried the SDK and the test succeeded. However, this does not mean that everything is OK: I tried then the SDK environment with my GNUPGHOME and I experience the same problem. So, I continued with the SDK resources only to see if the problem is with GNUPGHOME:

mkdir /tmp/test
cd /tmp/test
export GNUPGHOME=/tmp/test/gnupg
mkdir "${GNUPGHOME}"
# Using lib-gpg.sh setup
gpg --homedir "${GNUPGHOME}" --import /usr/src/git/t/lib-gpg/keyring.gpg
gpg --homedir "${GNUPGHOME}" --import-ownertrust /usr/src/git/t/lib-gpg/ownertrust
gpg --list-key
# Looks good to me
git init repo
cd repo
echo Hello > hello.txt
git add hello.txt && git commit -m "Test"
git tag -s test -m "Test"

Oops, here we go again. I got:

error: gpg failed to sign the data
error: unable to sign the tag

Which looks familiar and not good. Now I used only resources from the SDK, nothing mine. Did I something wrong?

[dscho]

@pdolezal thanks for your feedback. I reverted the commit that broke interactive GPG usage; the fix will be part of the next Git for Windows release. In the meantime, hopefully you can build and use your own custom installer via the SDK?

[pdolezal]

@dscho I'm just a pitiful Git user, who saw the SDK for the first time yesterday. So, I'll stay with the previous version for the time being and I'll upgrade to the next version that can sign again for me. Anyway thank you for fixing the problem.

[mjg]

Could any of the users here which see the problem please do the following:

1. Tell us your gpg version: gpg --version
2. Test whether you can gpg-sign in the terminal/shell that you are using for git: echo duh | gpg -sa (possibly specifying your key with u).

[jibsen]

1. Output from gpg --version:

   gpg (GnuPG) 2.0.30 (Gpg4win 2.3.3)
   libgcrypt 1.6.6
   

2. Signing from Conemu shell with the above command works fine.

   One thing to note, when I run gpg like this, it pops up a gpg agent window asking for the password, whereas if I sign a tag through git 2.9.0 it asks me on the command line. Perhaps git calls its own gpg.

[jibsen]

I just checked, and git has it's own gpg (1.4.20) in usr/bin, and I can sign a message from the command line with that one as well.

[dscho]

I'm just a pitiful Git user, who saw the SDK for the first time yesterday. So, I'll stay with the previous version for the time being and I'll upgrade to the next version that can sign again for me.

@pdolezal please note that it is very easy to make an installer once you already have an SDK: https://github.com/git-for-windows/git/wiki/Making-an-installer

[dscho]

Test whether you can gpg-sign in the terminal/shell that you are using for git: echo duh | gpg -sa (possibly specifying your key with u).

@mjg you are comparing Apples with Oranges. What you asked to test is a command-line that does not leave the POSIX-emulation layer called MSYS2: the terminal, the shell, as well as echo and gpg are _all_ MSYS2 programs.

When calling GPG from git.exe, though, you have a totally different scenario: git.exe is _not_ an MSYS2 program, it does not know about any POSIX emulation (including /dev/tty) and when it spawns a new process whose standard handles are all redirected, that new process has a _real hard time_ to find its way back to the original terminal window's /dev/tty.

[dscho]

Perhaps git calls its own gpg.

Nope.

[EDIT:]
It calls the one in /usr/bin/. That is MSYS2's gpg.

If you have another gpg in your PATH, then it may very well be overridden by Git's PATH munging.

[mjg]

you are comparing Apples with Oranges. What you asked to test is a command-line that does not leave the POSIX-emulation layer called MSYS2: the terminal, the shell, as well as echo and gpg are all MSYS2 programs.

I'm not comparing anything. I'm trying to pin-point the root cause without asserting blame.

When calling GPG from git.exe, though, you have a totally different scenario: git.exe is not an MSYS2 program, it does not know about any POSIX emulation (including /dev/tty) and when it spawns a new process whose standard handles are all redirected, that new process has a real hard time to find its way back to the original terminal window's /dev/tty.

This means that the recent gpg-sign change in git (which introduces no problem on Linux) exposes a problem in the way in which, on Windows, non-MSYS2-git interacts with MSYS2-gpg.

Reverting that change may be the best hot-fix, but not a solution.

[jibsen]

Perhaps git calls its own gpg.

Nope.

[EDIT:]
It calls the one in /usr/bin/. That is MSYS2's gpg.

Okay, I just meant one that the Git for Windows installer installs along with git, as opposed to the one I installed on the system.

Just to clarify, I am running these commands from the Windows command line, not from the Bash Git for Windows installs.

[dscho]

Could you give https://github.com/git-for-windows/git/releases/tag/prerelease-v2.10.0.windows.1.11.geda474c a try?

[pdolezal]

@dscho It looks good to me, I was able to make a signed tag and verify it, so I hope it will be fine, although this is not a thorough test ;-)

[dscho]

Thanks for the quick test ( even a quick test is better than no test at all)!