[16284] in athena10
Bug#914036: config-package-dev: scripts directly access internal dpkg database
daemon@ATHENA.MIT.EDU (Geoffrey Thomas)
Sun Feb 3 20:33:10 2019
Reply-To: Geoffrey Thomas <geofft@ldpreload.com>, <914036@bugs.debian.org>
Resent-From: Geoffrey Thomas <geofft@ldpreload.com>
Resent-To: <debian-bugs-dist@lists.debian.org>
Date: Sun, 3 Feb 2019 20:26:42 -0500 (EST)
From: Geoffrey Thomas <geofft@ldpreload.com>
To: Guillem Jover <guillem@debian.org>, 914036@bugs.debian.org
In-Reply-To: <20181118180951.GA19816@gaara.hadrons.org>
Message-ID: <alpine.DEB.2.11.1902031926150.4589@titan.ldpreload.com>
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="465974336-820210814-1549243602=:4589"
This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
--465974336-820210814-1549243602=:4589
Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed
Content-Transfer-Encoding: QUOTED-PRINTABLE
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
>
> Hi!
>
> This package contain scripts that directly access the dpkg internal
> database [S], instead of using the correct public interface
> =C2=ABdpkg --verify=C2=BB (note that it currently does not return an erro=
r 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=20
$package md5sums, and only fall back to /var/lib/dpkg/info when that=20
option doesn't exit. Is that enough?
(I can drop the fallback if you'd like - we wanted to support backports to=
=20
LTSes but that code was written in 2011 so any current supported release=20
certainly has --control-path. Relatedly, we could probably switch to=20
--control-show at this point too if you'd like, but see also=20
https://bugs.debian.org/735021 .)
I suppose we could use dpkg --verify, which would in theory simplify=20
the code because (if I'm testing it right) it handles conffiles and=20
non-conffiles just the same, and so we don't need a special case for=20
dpkg-query -W'${Conffiles}'. But there are two downsides to it:
- It's less efficient, since it verifies all files in the package instead=
=20
of just the one we want to check.
- As far as I can tell, it doesn't distinguish "This file has not been=20
modified" from "I have no md5sums for this file". It's very rare to see a=
=20
package with a missing or incomplete md5sums control file these days, but=
=20
we do handle that case currently (we print an error if it's incomplete,=20
and a warning if the package has no md5sums at all) and I'd like to keep=20
handling it.
Do you think you can extend the --verify interface to support querying an=
=20
individual file by name, and print an error if the file could not be=20
verified?
If you can do a dpkg --verify-file (where dpkg figures out the package=20
name, and prints an error if the file is unknown or the owning package=20
doesn't provide md5sums) then I can skip most of the complexity in what=20
I'm doing and just call that in newer versions of dpkg. :) I could also=20
use a dpkg --verify "$package" --verify-file "$file", or something.
--=20
Geoffrey Thomas
https://ldpreload.com
geofft@ldpreload.com
--465974336-820210814-1549243602=:4589--
