Package: gnupg-utils Version: 2.2.10-3 Severity: normal User: [email protected] 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
