installer: add option for external GnuPG #480
Conversation
Okeanos
changed the title
This pull request addresses git-for-windows/git/issues/3997 by adding an additional detection mechanism for externally supplied GnuPG binaries to a new choice page in the installer and allows the user to "skip" the installation of the bundled GPG related binaries. Signed-off-by: Nikolas Grottendieck <[email protected]>
Okeanos
force-pushed
the
feature/external-gpg
branch
from
e8d408d
to
8451878
Compare
The solution to that riddle is: $ pacman -Qo /usr/bin/gpg-error.exe
/usr/bin/gpg-error.exe is owned by libgpg-error 1.42-2There should be also a left-over $ pacman -Ql libgpg-error | grep -v locale
libgpg-error /usr/
libgpg-error /usr/bin/
libgpg-error /usr/bin/gpg-error.exe
libgpg-error /usr/bin/msys-gpg-error-0.dll
libgpg-error /usr/bin/yat2m.exe
libgpg-error /usr/share/We probably need to remove the contents of that package, too. In general, it might be a bit more complicated than just listing one or two packages' contents: $ pactree gnupg
gnupg
├─bzip2
│ └─libbz2
│ └─gcc-libs
├─libassuan
│ ├─gcc-libs
│ └─libgpg-error
│ ├─bash provides sh
│ ├─libiconv
│ │ ├─gcc-libs
│ │ └─libintl
│ │ ├─gcc-libs
│ │ └─libiconv
│ └─libintl
├─libbz2
├─libcurl
│ ├─ca-certificates
│ │ ├─bash
│ │ ├─openssl
│ │ │ ├─libopenssl
│ │ │ │ └─zlib
│ │ │ │ └─gcc-libs
│ │ │ └─zlib
│ │ ├─findutils
│ │ │ ├─libiconv
│ │ │ └─libintl
│ │ ├─coreutils
│ │ │ ├─gmp
│ │ │ ├─libiconv
│ │ │ └─libintl
│ │ ├─sed
│ │ │ ├─libintl
│ │ │ └─bash provides sh
│ │ └─p11-kit
│ │ └─libp11-kit=0.24.1
│ │ ├─libffi
│ │ ├─libintl
│ │ └─libtasn1
│ │ └─info
│ │ ├─gzip
│ │ │ ├─bash
│ │ │ └─less
│ │ │ ├─ncurses
│ │ │ │ └─gcc-libs
│ │ │ └─libpcre2_8
│ │ │ └─gcc-libs
│ │ ├─libcrypt
│ │ │ └─gcc-libs
│ │ ├─libintl
│ │ └─ncurses
│ ├─heimdal-libs
│ │ ├─libcrypt
│ │ ├─libedit
│ │ │ ├─ncurses
│ │ │ └─bash provides sh
│ │ ├─libsqlite
│ │ │ ├─libreadline
│ │ │ │ └─ncurses
│ │ │ ├─zlib
│ │ │ └─tcl
│ │ │ └─zlib
│ │ └─libopenssl
│ ├─libcrypt
│ ├─libidn2
│ │ ├─libunistring
│ │ │ └─libiconv
│ │ └─libintl
│ ├─libnghttp2
│ │ └─gcc-libs
│ ├─libpsl
│ │ ├─libxslt
│ │ │ ├─libxml2
│ │ │ │ ├─coreutils
│ │ │ │ ├─liblzma
│ │ │ │ │ ├─bash provides sh
│ │ │ │ │ ├─libiconv
│ │ │ │ │ └─gettext
│ │ │ │ │ ├─libintl
│ │ │ │ │ ├─libgettextpo
│ │ │ │ │ │ └─gcc-libs
│ │ │ │ │ └─libasprintf
│ │ │ │ │ └─gcc-libs
│ │ │ │ ├─libreadline
│ │ │ │ └─zlib
│ │ │ └─libgcrypt
│ │ │ └─libgpg-error
│ │ ├─libidn2
│ │ └─libunistring
│ ├─libssh2
│ │ ├─ca-certificates
│ │ ├─openssl
│ │ └─zlib
│ ├─openssl
│ └─zlib
├─libgcrypt
├─libgpg-error
├─libgnutls
│ ├─gcc-libs
│ ├─libidn2
│ ├─libiconv
│ ├─libintl
│ ├─gmp
│ ├─libnettle
│ │ └─libhogweed
│ │ └─gmp
│ ├─libp11-kit
│ ├─libtasn1
│ └─zlib
├─libiconv
├─libintl
├─libksba
│ ├─gcc-libs
│ └─libgpg-error
├─libnpth
│ └─gcc-libs
├─libreadline
├─libsqlite
├─nettle
│ └─libnettle
├─pinentry
│ ├─ncurses
│ ├─libassuan
│ └─libgpg-error
└─zlibSome of these are shared with other dependencees, e.g. $ pactree -r libreadline | grep awk
├─gawkBut others do need to be removed, too, e.g. $ pactree -r pinentry
pinentry
└─gnupg
├─libgpgme
└─pacman
├─pacman-contrib
└─pkgfileI have to admit that I am not completely certain how best to handle this. One option might be to modify diff --git a/make-file-list.sh b/make-file-list.sh
index 9960b4809..39d305994 100755
--- a/make-file-list.sh
+++ b/make-file-list.sh
@@ -166,10 +166,11 @@ mingw-w64-$PACMAN_ARCH-git-extra openssh $UTIL_PACKAGES"
if test -z "$MINIMAL_GIT"
then
packages="$packages mingw-w64-$PACMAN_ARCH-git-doc-html ncurses mintty vim nano
- winpty less gnupg tar diffutils patch dos2unix which subversion perl-JSON
+ winpty less tar diffutils patch dos2unix which subversion perl-JSON
mingw-w64-$PACMAN_ARCH-tk mingw-w64-$PACMAN_ARCH-connect git-flow docx2txt
mingw-w64-$PACMAN_ARCH-antiword mingw-w64-$PACMAN_ARCH-odt2txt ssh-pageant
mingw-w64-$PACMAN_ARCH-git-lfs mingw-w64-$PACMAN_ARCH-xz tig $GIT_UPDATE_EXTRA_PACKAGES"
+ test -n "$SKIP_GNUPG" || packages="$packages gnupg"
fi
pacman_list $packages "$@" |
combined with this call: comm -23 <(ARCH=x86_64 ./make-file-list.sh | sort) <(SKIP_GNUPG=1 ARCH=x86_64 ./make-file-list.sh | sort)But that means that we run Plus: That would miss Tricky business.
Those are long-running services (but not Windows Services, more like Unix daemons) that are used only by GnuPG. So yes, it is good that they're being removed together with |
|
Thanks for the in depth review and suggestions on how to proceed – I'll have a look in a while. Currently a little swamped with everything. |
@Okeanos that's exactly the same reason why it took me so long to get to review your PR, sorry! |
|
Just as a reminder (also to myself) I am still willing to work on this (unless somebody would like to do the honors instead). However, I am not sure I have the mental fortitude to deal with this for a while yet. It's a non-trivial problem and I would like to give it an earnest effort in thinking through a potential solution. If anything changes substantially with the existing scripts (i.e. causes merge conflicts) I'll likely update the PR "as-is" to be at least in a state that can be build upon. |
|
An easier-to-achieve alternative comes to mind: instead of deleting |
|
@dscho that sounds similar to what happened with the original SSH setup stuff: it only works for git specifically but other programs may want to use the same GPG executable correctly as well and obviously will use it as found on The I'll mull it over some more and hope I have time to actively work on this soon™ again. |
|
Fair enough. |
This pull request addresses git-for-windows/git/issues/3997 by adding an additional detection mechanism for externally supplied GnuPG binaries to a new choice page in the installer and allows the user to "skip" the installation of the bundled GPG related binaries.
Notes:
The full list of stuff that will not be installed (
pacman -Ql gnupg):Interestingly the
Git\usr\binfolder still contains thegpg-error.exeafter selecting "external GPG"; everything else (that has gpg in its name) looks correctly removed.Additionally, there are e.g.
dirmngr-client.exeanddirmngr.exethat also get removed (as they are part of the gnupg package). I have no idea what the implications of this are.Detection of the
wingetpackagesGnuPG.GnuPGandGnuPG.Gpg4winin the installer works fine: the GPG selection page is only shown if e.g. one of them is installed. Otherwise the installation proceeds as it always did and uses internal GPG.