Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg
On Sat, 2022-06-25 at 22:09:12 +0200, Salvatore Bonaccorso wrote: > In fact I think this regression can be included as fix in the upcoming > point releases if SRM agree, and so avoid an out of order dpkg update > again to fix this rather edge-case regression (and instread batch it > with other updates for the point releases). Yes, was planning to do that after uploading this fix to unstable. But got sick and was not able to do much. > Did you found time already for fixes? The bullseye 11.4 point release > has now been settled for the July 9th, with freezing the upload window > the preceeding weekend. I'll try to finish this up for today, and send a proposal for a stable update once this hits unstable. Thanks, Guillem
Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg
Hi, On Wed, Jun 01, 2022 at 03:53:32AM +0200, Guillem Jover wrote: > Hi! > > On Tue, 2022-05-31 at 22:10:29 +0200, Paul Gevers wrote: > > Source: dpkg > > Version: 1.20.10 > > Severity: important > > > Our proposed-updates queue [1] show regressions in the autopkgtest of > > lintian with the security version of dpkg. Looking at the logs [2], it > > appears to me that the file permissions of files in the test > > change. If I understand the security issue correctly, I don't think > > that was intended. Again, I may be reading the signs wrong, but I > > suspect you want to have a look. > > Hmm, right. We noticed this on the new security queue autopkgtest > infra, and I checked locally and it was reproducible, but for some > reason I disregarded it as not relevant. :/ > > Perhaps because it was not showing up on lintian's sid test suite (but > just checked now and the test seems to have been removed from there), > and I'm assuming I didn't test against the previous dpkg version. So, > it seems I botched the testing procedure somewhere. > > In any case, I think the attached patch fixes this, which during the > days I was preparing the fix this came to mind to take into account, > but I guess I forgot along the way. :/ I'll test this tomorrow against > the older lintian test suite. I guess I'll need to talk with the > security team avoid issuing a security fixup? In fact I think this regression can be included as fix in the upcoming point releases if SRM agree, and so avoid an out of order dpkg update again to fix this rather edge-case regression (and instread batch it with other updates for the point releases). Did you found time already for fixes? The bullseye 11.4 point release has now been settled for the July 9th, with freezing the upload window the preceeding weekend. Thank you Guillem for your work! Regards, Salvatore
Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg
Hi!
On Tue, 2022-05-31 at 22:10:29 +0200, Paul Gevers wrote:
> Source: dpkg
> Version: 1.20.10
> Severity: important
> Our proposed-updates queue [1] show regressions in the autopkgtest of
> lintian with the security version of dpkg. Looking at the logs [2], it
> appears to me that the file permissions of files in the test
> change. If I understand the security issue correctly, I don't think
> that was intended. Again, I may be reading the signs wrong, but I
> suspect you want to have a look.
Hmm, right. We noticed this on the new security queue autopkgtest
infra, and I checked locally and it was reproducible, but for some
reason I disregarded it as not relevant. :/
Perhaps because it was not showing up on lintian's sid test suite (but
just checked now and the test seems to have been removed from there),
and I'm assuming I didn't test against the previous dpkg version. So,
it seems I botched the testing procedure somewhere.
In any case, I think the attached patch fixes this, which during the
days I was preparing the fix this came to mind to take into account,
but I guess I forgot along the way. :/ I'll test this tomorrow against
the older lintian test suite. I guess I'll need to talk with the
security team avoid issuing a security fixup?
Thanks,
Guillem
diff --git i/scripts/Dpkg/Source/Package/V2.pm w/scripts/Dpkg/Source/Package/V2.pm
index 1167625d7..68a967168 100644
--- i/scripts/Dpkg/Source/Package/V2.pm
+++ w/scripts/Dpkg/Source/Package/V2.pm
@@ -218,7 +218,7 @@ sub do_extract {
# Extract main tarball
info(g_('unpacking %s'), $tarfile);
my $tar = Dpkg::Source::Archive->new(filename => "$dscdir$tarfile");
-$tar->extract($newdirectory, no_fixperms => 1,
+$tar->extract($newdirectory,
options => [ '--anchored', '--no-wildcards-match-slash',
'--exclude', '*/.pc', '--exclude', '.pc' ]);
# The .pc exclusion is only needed for 3.0 (quilt) and to avoid
@@ -239,7 +239,7 @@ sub do_extract {
erasedir("$newdirectory/$subdir");
}
$tar = Dpkg::Source::Archive->new(filename => "$dscdir$file");
-$tar->extract("$newdirectory/$subdir", no_fixperms => 1);
+$tar->extract("$newdirectory/$subdir");
}
# Stop here if debianization is not wanted
Bug#1012195: dpkg: lintian autopkgtest *may* have spotted a regression in security update of dpkg
Source: dpkg Version: 1.20.10 Severity: important Dear Guillem, Our proposed-updates queue [1] show regressions in the autopkgtest of lintian with the security version of dpkg. Looking at the logs [2], it appears to me that the file permissions of files in the test change. If I understand the security issue correctly, I don't think that was intended. Again, I may be reading the signs wrong, but I suspect you want to have a look. Paul # Tags do not match # # --- ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/permissions/legacy-scripts/tags.specified.calibrated # +++ ../../autopkgtest_tmp/build-and-evaluate-test-packages/eval/checks/files/permissions/legacy-scripts/tags.actual.parsed # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 777 tkfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 777 gccbug.dpatch # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 777 envfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 xsession-test # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 wishfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 suidperlfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 sh-broken # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 rubyfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 phpfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 phpenvfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 perlfoo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 perl-bizarre-3 # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 perl-bizarre-2 # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 perl-bizarre-1 # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 make-foo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 lefty-foo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 jruby-broken # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 init-skeleton # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 init-no-lsb # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 init-lsb-other # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 init-lsb-broken # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 guile-bizarre # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 fish-foo # -scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 666 csh-foo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 755 tkfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 755 gccbug.dpatch # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 755 envfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 xsession-test # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 wishfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 suidperlfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 sh-broken # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 rubyfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 phpfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 phpenvfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 perlfoo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 perl-bizarre-3 # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 perl-bizarre-2 # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 perl-bizarre-1 # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 make-foo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 lefty-foo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 jruby-broken # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 init-skeleton # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 init-no-lsb # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 init-lsb-other # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 init-lsb-broken # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 guile-bizarre # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 fish-foo # +scripts (source): octal-permissions scripts_6ds-1ubuntu0.5.10.1.dsc 644 csh-foo # [1] https://release.debian.org/propo
