gpg unable to generate absolute path for windows drives

[cmllamas]

• 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? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.19.1.windows.1
cpu: x86_64
built from commit: 11a3092e18f2201acd53e45aaa006f1601b6c02a
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 10.0.16299.665]

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

$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Builtin Rebase: Disabled
Enable Builtin Stash: Disabled

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

I'm using git-repo adapted for windows

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.

I'm running 'repo init', ultimately the problematic command is:
$ gpg --homedir='C:\Users\uidw3762/.repoconfig-esrlabs\gnupg' --import

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

This is the output on Git-2.18.0-64...
$ gpg --homedir='C:\Users\uidw3762/.repoconfig-esrlabs\gnupg' --import key
gpg: keyring `C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/secring.gpg' created
gpg: keyring `C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/pubring.gpg' created
gpg: C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/trustdb.gpg: trustdb created
gpg: key F494ADA3: public key "Repo Maintainer <repo@esrlabs.com>" imported
gpg: key B566A02A: public key "E.S.R.Labs <matthias.putz@esrlabs.com>" imported
gpg: Total number processed: 2
gpg:               imported: 2  (RSA: 2)

$ gpg --version
gpg (GnuPG) 1.4.22
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

• What actually happened instead?

$ gpg --homedir='C:\Users\uidw3762/.repoconfig-esrlabs\gnupg' --import key
gpg: keyblock resource '/d/vuc/C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/pubring.kbx': No such file or directory
gpg: no writable keyring found: Not found
gpg: error reading 'key': General error
gpg: import from 'key' failed: General error
gpg: Total number processed: 0

$ gpg --version
gpg (GnuPG) 2.2.9-unknown
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

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

no

[cmllamas]

This might as well be a gpg specific issue, but basically any command not using default home directory for gpg on git bash will fail to expand windows paths.

[cmllamas]

I just cloned the source and rebuilt with "#define HAVE_DRIVE_LETTERS 1" and drives are properly expanded now:
$ ./g10/gpg.exe --homedir='C:\Users\uidw3762/.repoconfig-esrlabs\gnupg' --import ../key
gpg: WARNING: unsafe permissions on homedir 'C:\Users\uidw3762/.repoconfig-esrlabs\gnupg'
gpg: keybox 'C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/pubring.kbx' created
gpg: C:\Users\uidw3762/.repoconfig-esrlabs\gnupg/trustdb.gpg: trustdb created
gpg: key 8A147132F494ADA3: public key "Repo Maintainer repo@esrlabs.com" imported
gpg: key DA39D1E1B566A02A: public key "E.S.R.Labs matthias.putz@esrlabs.com" imported
gpg: Total number processed: 2
gpg: imported: 2

Maybe configure.ac from gnupg isn't properly defining environment for mingw.

[dscho]

Sorry, this ticket totally fell under my radar :-(

The GNU Privacy Guard version we are using is compiled from https://github.com/msys2/MSYS2-packages/tree/master/gnupg. I do not see anything in the history of that directory that would suggest that they fixed the drive letter issue.

So this is how you can help: investigate a little further why #define HAVE_DRIVE_LETTERS 1 is missing. To do that,

1. install Git for Windows' SDK,
2. Initialize the local clone by sdk cd MSYS2-packages
3. Get the upstream changes: git remote add -f upstream https://github.com/msys2/MSYS2-packages
4. Check out a new branch from upstream's master: git checkout -b fix-gnupg-abspath upstream/master
5. Build the gnupg package: cd gnupg && makepkg -s (you might need to import some GPG keys first, and trust them, for makepkg to build that package)
6. Look for the gpg.exe somewhere inside src/ and test it, and/or look at the sources in src/ to see where the constant should be defined but is not.

My hunch is that ./configure would need an option to get that constant defined: https://github.com/msys2/MSYS2-packages/blob/66b63291166362d8cbf1a4370dae20e2ae9e18b6/gnupg/PKGBUILD#L68

[cmllamas]

thanks for the detailed steps, l can check and see if there's a configure option for drive letters. I'll provide an update soon.
I see AC_FUNC_MMAP is failing though...

configure: error: Sorry, the current implementation requires mmap.
==> ERROR: A failure occurred in build().
    Aborting...

I disable the check for now, but any hints as to why I got this issue? missing dependencies? I see I do have /sys/mmap.h header file installed.

EDIT: never mind the mmap error, still new to this repo and I was building the package from the wrong shell (not msys2_shell). so it's probably that.

[cmllamas]

@dscho I was able to build and confirm issue still there with gnupg-2.2.13.
I couldn't find any configure option that would end up defining HAVE_DRIVE_LETTERS though.
What I did was patch force that option on configure.ac and that did the trick:

@@ -652,6 +652,10 @@ use_ldapwrapper=yes
 mmap_needed=yes
 require_pipe_to_unblock_pselect=yes
 case "${host}" in
+    *-msys*)
+        AC_DEFINE(HAVE_DRIVE_LETTERS,1,
+                  [Defined if the OS supports drive letters.])
+            ;;
     *-mingw32*)
         # special stuff for Windoze NT
         ac_cv_have_dev_random=no

adding the -msys pattern to the -mingw32 case only brakes the build, it defines a bunch of other environment variables.
I'll investigate what changed from when using gnupg 1, maybe a similar patch was left behind.

[dscho]

@cmllamas excellent progress!

[cmllamas]

@dscho, I checked out the following sdk (gpg1 was being used):

• MSYS2-packages @603b7e143
• git-sdk-64 @14ae0053

I rebuilt gpg package and confirmed windows paths where properly being expanded, just as expected.
So I started gdb sessions to do a side-by-side run with gpg1 and gpg2.
I turns out gpg2 processes the --homedir argument using a "make_absfilename()" function, here is where the path gets incorrectly expanded without the HAVE_DRIVE_LETTERS definition. This is the relevant piece of code in gnupg-2.2.13/common/stringhelp.c

 508 #ifdef HAVE_DRIVE_LETTERS
 509       p = strchr (name, ':');
 510       if (p)
 511         p++;
 512       else
 513         p = name;
 514 #else
 515       p = name;
 516 #endif
 517       if (*p != '/'
 518 #ifdef HAVE_DRIVE_LETTERS
 519           && *p != '\\'
 520 #endif
 521           )

gpg1 does not process the homedir and that is the difference between the two versions and why they behave differently.

I'm thinking HAVE_DRIVE_LETTERS feature should have probably been defined for both versions of gpg on msys2? I only see a few parts on gpg1 where the definition is even being used, so no point on changing that I suppose.
As for gpg2, I would assume the cleanest way to include this feature would by adding something similar to what I provided on my previous comment to the gnupg-*-msys2.patch.

What do you think of this? Next steps?

[dscho]

I'm thinking HAVE_DRIVE_LETTERS feature should have probably been defined for both versions of gpg on msys2

Agreed!

As for gpg2, I would assume the cleanest way to include this feature would by adding something similar to what I provided on my previous comment to the gnupg-*-msys2.patch.

Agreed, too!

what I provided on my previous comment to the gnupg-*-msys2.patch.

What do you think of this? Next steps?

Excellent work!

I think the logical next steps would be a PR to https://github.com/git-for-windows/MSYS2-packages that adds and applies that patch. Just make sure that autoreconf -fiv is called in PKGBUILD (unless it is already called).

[cmllamas]

ok, here it is: git-for-windows/MSYS2-packages#33