[pkg-gnupg-maint] Bug#913582: gpg-zip: wrong default TAR path if built on a merged-/usr system and used on an unmerged-/usr system

[Simon McVittie]

Package: gnupg-utils
Version: 2.2.10-3
Severity: normal
User: md at linux.it
Usertags: usrmerge

gnupg2 appears to have a build bug that can be reproduced as follows
(I haven't actually tested this myself):

* Have two systems/chroots/containers, one with merged /usr (/bin is a
  symlink to /usr/bin) and one without
* Build gnupg2 on the first system
* Install it on the second system and use gpg-zip

Expected result:

* gpg-zip invokes /bin/tar (or just tar as found in PATH) and succeeds

Actual result:

* gpg-zip invokes /usr/bin/tar and fails

----

I recently added a new point of variation (#901473) to Debian's
reproducible builds infrastructure: the first build is done in a
traditional Debian system with separate /bin and /usr/bin, while the
second is done with merged /usr (/bin is a symbolic link to /usr/bin).

gnupg2 appears to have the class of bug that this was meant to detect.
If you look at
https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/gnupg2.html
you'll see that in the first build, gpg-zip has

VERSION=2.2.10
TAR=/bin/tar
GPG=gpg

whereas in the second, gpg-zip has

VERSION=2.2.10
TAR=/usr/bin/tar
GPG=gpg

When gpg-zip invokes $TAR, for example in "$TAR -xvf -", on a system
without merged /usr, it will only work if TAR is /bin/tar (or just "tar").

This can probably be fixed by passing TAR=/bin/tar to the configure script.

Mitigation: if you do source-only uploads, the older debootstrap currently
in use on buildds will create non-merged-/usr schroot tarballs, so users
will not currently experience this bug. (However, if stretch-backports'
debootstrap is brought up to date with buster and deployed to buildds
without first applying #913228, that mitigation will go away.)

    smcv