Re: debsums for maintainer scripts (was: Re: Revival of the signed debs discussion)
Eduard Bloch <edi@gmx.de> writes:
> #include <hallo.h>
> John Goerzen schrieb am Monday, den 01. December 2003:
>
> > Debsigs generates its signature by effectively cating the control and
> > data components of the ar file together, running that through gpg, and
> > storing the resulting signature data in a new component of the ar file.
> > I did test this back in 2001 and the code caused no problem for dpkg
> > extraction. In short, if a system does not use debsigs, the whole
> > signature is invisible to the system tools.
>
> Kinda off-topic but nowhere in the discussion the question of checking
> already installed files was adressed and it should be asked:
>
> are there any plans to store md5sums of the maintainer scripts along
> with the current one that are already created for the data.tar.gz
> contents? I imagine an attacker to place a time bomb into a prerm script
> of an installed package and wait for his next chance.
>
> AFAICS the only way to verify the contents of maintainer scripts
> automaticaly is to have the binary package, verify its contents via
> .changes or Release/Packages path, extract it and compare the files. Too
> complicated.
>
> I would like to see the following things happen:
>
> - current md5sums file in control.tar.gz should contain
> checksums of really all files
> - a signature of the md5sums file should be stored either in
> control.tar.gz or in the ar file itself
> - new dpkg version should pickup the signature files and store them
> either in /var/lib/dpkg/info or in some alternative directory
> - modify debsums to check the signature as well as maintainer scripts'
> checksums
>
> Any additions, comments, etc.?
If you think files of a deb are compromised on your system what makes
you thing the md5sum files are not? Storing the md5sum files on-site
will only help against accidental (or stupid) changes.
Also since the complete deb is just as save as the md5sumsfile
contained in the deb it is pointless to have such. People who realy
want to store the md5sums file should create it during install time
(let dpkg do that). The md5sums file still requires one to download
the complete deb from a trusted source to verify the installed
system. But then why not just do a 1:1 compare?
After all this ranting about how useless a md5sums file is here's an
idea:
1. No md5sums files are contained in the deb itself.
2. dpkg-genchanges unpacks the deb (control and data) and creates a
sorted md5sums file (sorted by md5sum, by filename or whatever. But
reproducible). A signature of the md5sums file (md5sum of it?) is
then added to the change file.
To save time dpkg-deb could build the md5sums file and
dpkg-genchanges gets told where to find it. But dpkg-genchanges
should be able to create it on its own too.
3. dinstall include the md5sums-file-signature in the Packages.gz
file.
The md5sums file can be recreated at any time from the locally
installed package. Computing the signature of it and comparing it to
the Packages file entry is then easy. If the signature doesn't match
we know that at least one file of the package has been changed. In
that case the pristine package can be downloaded to investigate what
was changed.
MfG
Goswin
PS: Maybe when introducing that a change to SHA1 could be done too.
Reply to: