Bug#944965: debsums: Script accesses internal dpkg database

[Guillem Jover]

Hi!

On Fri, 2020-05-22 at 01:06:51 +0200, Axel Beckert wrote:
> Control: tag -1 moreinfo

> Guillem Jover wrote:
> > This package contains the «debsums» program, which directly accesses
> > the dpkg internal database, instead of using one of the public
> > interfaces provided by dpkg.
> 
> JFTR: This is not true. I didn't find a single place in the debsums
> script where $admindir is accessed directly. Instead it is always
> passed to a dpkg, dpkg-query or dpkg-divert call as you asked for.

Well I see in debsums the md5sums_path() function which does access
it. And the debsums_init program does too indeed. :)

> The only script which accesses *.md5sums files and only to see if they
> exist, is debsums_init which is meant to be removed anyway, once
> https://lintian.debian.org/tags/no-md5sums-control-file.html is down
> to zero as it actually generates that file. But since there are
> currently over 60 packages on that list, this won't be anytime soon.

As you have noticed (down below), dpkg has been generating missing
md5sum on installation for some time, so this functionality does not
seem necessary anymore. Also «dpkg -C» will warn about packages that
are still missing such files so that they can be reinstalled.

> > The admindir can also be configured differently at dpkg build or
> > run-time.
> 
> Well, that's exactly what we do: We configure dpkg's admindir at
> run-time!

> W only use $admindir and provide it to dpkg as parameter because
> debsums supports to also check chroots. And since chroots might be of
> a different architecture (or for forensic purposes), we don't want to
> use the dpkg binary inside the chroot, i.e. we need to provide at
> least the location to dpkg. And for that, we need to know it.

My point is that if dpkg has been built with a different admindir
default (not the case in Debian, but perhaps a derivative system)
then debsums passing that pathname will make dpkg operate on an
invalid database (and with newer versions it will simply consider
that a bootstrapping installation and proceed as if it had 0 packages
installed).

Ideally debsums would only pass the admindir if it has been specified.
And then it would also only use --root on dpkg commands if that's what
has been passed to it, which would imply no need for a hard-coded
dpkg database pathname.

Of course one problem is that dpkg-query does not have a --root
option! But I think I have a branch somewhere implementing that, so
I'll add this to 1.20.1. :)

> Leaves the build-time configuration of the admindir: How can I query
> dpkg for the build-time location of its admindir?
> 
> And how can I determine the admindir of a chroot with a call to an
> external dpkg binary outside the chroot, which, as I understand you,
> can have a different admindir.

So with the above, the idea would be that you do not need to.

> > The debsums program should be switched to use something like:
> > 
> >   «dpkg-query --control-show $pkg md5sums»
> >
> > to get the md5sums file contents. If the file is missing an error
> > will be returned.
> 
> I just tried "dpkg-query --control-show sendfile md5sums" in a minimal
> pbuilder chroot where I just installed sendfile to see how that error
> looks like.
> 
> To my surprise, despite sendfile_2.1b.20080616-6_amd64.deb does not
> contain a files with md5sums, "dpkg-query --control-show sendfile
> md5sums" works and /var/lib/dpkg/info/sendfile.md5sums exists.
> 
> So it seems as if dpkg now automatically generates md5sums files if
> not present. Just checked dpkg's changelog and this feature seems to
> exist since 2012.
> 
> Which means that debsums_init is actually obsolete since 2012.
> 
> So I will happily remove debsums_init with the next upload.:-)

Yes, thanks. :)

> > If the file is missing an error will be returned.
> 
> So how can this file be missing if dpkg generates them?

That would be the case if a package had been installed with an ancient
dpkg version and then never upgraded. But as mentioned above «dpkg -C»
will complain, so I'd leave it to the user to handle TBH. Also because
generating the md5sums from the installed files is a bit misleading as
if they have changed then they will be "bogus", I mean I guess this is
better than nothing, but not ideal.

Thanks,
Guillem