Package: perl Version: 5.30.3-4 Severity: important User: de...@kali.org Usertags: origin-kali X-Debbugs-Cc: debian-d...@lists.debian.org Control: found -1 5.32.0-2
In Kali, any source package build started to fail with a mysterious error: > dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127 After quite some investigation, I tracked this down to perl exiting with that error code in the middle of an eval statement that should have failed: https://sources.debian.org/src/dpkg/1.20.5/scripts/Dpkg/Vendor.pm/#L166 The $name tried is "Kali" and we don't ship any Dpkg::Vendor::Kali. The code should fallback to Dpkg::Vendor::Debian and this works a few times but after multiples calls, at some point it no longer works and the require statement in the eval block just never returns, it seems to crash the perl interpreter. You can easily reproduce this on an up-to-date testing or unstable system with dpkg 1.20.5 (that version is failing, the former version we had in Kali was 1.19.7 and it was not triggering this issue): $ sudo tee /etc/dpkg/origins/kali >/dev/null <<END > Vendor: Kali > Vendor-URL: https://www.kali.org/ > Parent: debian > Bugs: https://bugs.kali.org/ > END $ sudo ln -sf kali /etc/dpkg/origins/default $ apt source hello [...] $ cd hello-* $ dpkg-buildpackage -S [...] dpkg-source -b . dpkg-source: info: using source format '3.0 (quilt)' dpkg-source: info: building hello using existing ./hello_2.10.orig.tar.gz dpkg-buildpackage: error: dpkg-source -b . subprocess returned exit status 127 Note that I only reproduce this with "3.0 (quilt)" source packages. Native packages have different code paths likely involving fewer calls to run_vendor_hook() and the problem can't be reproduced with such a source package. I can also reproduce the bug with version 5.32.0-2 available in experimental. FWIW I'm working around this issue in Kali with the attached patch but this really smells like a bug in perl, thus I'm reporting it here. Guillem, I believe the attached patch should be applied to dpkg in any case as it's a small optimization that avoids running the evaled code too often. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.7.0-3-amd64 (SMP w/4 CPU threads) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages perl depends on: ii dpkg 1.20.5 ii libperl5.30 5.30.3-4 ii perl-base 5.30.3-4 ii perl-modules-5.30 5.30.3-4 Versions of packages perl recommends: ii netbase 6.1 Versions of packages perl suggests: pn libtap-harness-archive-perl <none> ii libterm-readline-gnu-perl 1.36-2+b1 ii make 4.3-4 ii perl-doc 5.30.3-4 -- no debconf information
>From 75631da697b9d2c5b3ff2c54bc225fc55d3ab9c2 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Rapha=C3=ABl=20Hertzog?= <raph...@offensive-security.com> Date: Thu, 3 Sep 2020 11:26:58 +0200 Subject: [PATCH] Work-around a perl crash during any package build Somehow perl doesn't like the multiple execution of the eval code that tries to "require Dpkg::Vendor::Kali;" and at some point perl just exits with an error code of 127 when it tries to execute this line of code. When it happens, the eval doesn't return. To avoid the multiple execution of this code, we cache the result of the lookup made on the parent vendor as the good result for the current vendor as well. There's likely some bug in perl here and somehow the update from dpkg 1.19.7 to dpkg 1.20.5 started to trigger that bug. --- scripts/Dpkg/Vendor.pm | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/scripts/Dpkg/Vendor.pm b/scripts/Dpkg/Vendor.pm index 196159156..5b8f66fd8 100644 --- a/scripts/Dpkg/Vendor.pm +++ b/scripts/Dpkg/Vendor.pm @@ -174,10 +174,12 @@ sub get_vendor_object { my $info = get_vendor_info($vendor); if (defined $info and defined $info->{'Parent'}) { - return get_vendor_object($info->{'Parent'}); + $obj = get_vendor_object($info->{'Parent'}); } else { - return get_vendor_object('Default'); + $obj = get_vendor_object('Default'); } + $OBJECT_CACHE{$vendor} = $obj; + return $obj; } =item run_vendor_hook($hookid, @params) -- 2.28.0