[16297] in athena10
Bug#914036: config-package-dev: scripts directly access internal dpkg database
daemon@ATHENA.MIT.EDU (Guillem Jover)
Wed Feb 6 07:15:16 2019
Reply-To: Guillem Jover <guillem@debian.org>, <914036@bugs.debian.org>
Resent-From: Guillem Jover <guillem@debian.org>
Resent-To: <debian-bugs-dist@lists.debian.org>
Date: Wed, 6 Feb 2019 13:13:17 +0100
From: Guillem Jover <guillem@debian.org>
To: Geoffrey Thomas <geofft@ldpreload.com>
CC: <914036@bugs.debian.org>
Message-ID: <20190206121317.GA13210@thunder.hadrons.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <alpine.DEB.2.11.1902031926150.4589@titan.ldpreload.com>
Control: severity -1 normal
Control: user debian-dpkg@lists.debian.org
Control: usertags -1 = dpkg-db-access-inert
Hi!
On Sun, 2019-02-03 at 20:26:42 -0500, Geoffrey Thomas wrote:
> On Sun, 18 Nov 2018, Guillem Jover wrote:
> > Source: config-package-dev
> > Source-Version: 5.5
> > Severity: important
> > User: debian-dpkg@lists.debian.org
> > Usertags: dpkg-db-access-blocker
> > This package contain scripts that directly access the dpkg internal
> > database [S], instead of using the correct public interface
> > «dpkg --verify» (note that it currently does not return an error exit
> > code when it finds modified files, that will be fixed in 1.19.3, but
> > you can always just check the output).
> >
> > [S] check-files.mk, dh_configpackage
>
> Both check-files.mk and dh_configpackage use dpkg-query --control-path
> $package md5sums, and only fall back to /var/lib/dpkg/info when that option
> doesn't exit. Is that enough?
>
> (I can drop the fallback if you'd like - we wanted to support backports to
> LTSes but that code was written in 2011 so any current supported release
> certainly has --control-path.
Ah right, sorry, I guess I skimmed too quickly! Removing the support
would make scanning for this kind of thing less error prone at least,
it might also avoid others copying this pattern. :)
> Relatedly, we could probably switch to
> --control-show at this point too if you'd like, but see also
> https://bugs.debian.org/735021 .)
TBH I think all the current --control-* interfaces are lacking in one
way or another. :(
> I suppose we could use dpkg --verify, which would in theory simplify the
> code because (if I'm testing it right) it handles conffiles and
> non-conffiles just the same, and so we don't need a special case for
> dpkg-query -W'${Conffiles}'.
Yes.
> But there are two downsides to it:
>
> - It's less efficient, since it verifies all files in the package instead of
> just the one we want to check.
Right, this is something I've been meaning to improve on, because it's
very annoying that you cannot do something like «dpkg -V /etc» f.ex.
> - As far as I can tell, it doesn't distinguish "This file has not been
> modified" from "I have no md5sums for this file". It's very rare to see a
> package with a missing or incomplete md5sums control file these days, but we
> do handle that case currently (we print an error if it's incomplete, and a
> warning if the package has no md5sums at all) and I'd like to keep handling
> it.
This should not be the case for some time now, as dpkg itself will
guarantee that there's always an md5sums file during unpack time,
either shipped by the package or generated internally.
> Do you think you can extend the --verify interface to support querying an
> individual file by name, and print an error if the file could not be
> verified?
> If you can do a dpkg --verify-file (where dpkg figures out the package name,
> and prints an error if the file is unknown or the owning package doesn't
> provide md5sums) then I can skip most of the complexity in what I'm doing
> and just call that in newer versions of dpkg. :) I could also use a dpkg
> --verify "$package" --verify-file "$file", or something.
Yeah, will try to get that in for 1.19.x.
Thanks,
Guillem
