Re: debsums for maintainer scripts
"Bernhard R. Link" <blink@informatik.uni-freiburg.de> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031204 02:46]:
> > "Bernhard R. Link" <blink@informatik.uni-freiburg.de> writes:
> > > I don't think so. md5-calculation it not the fastest thing (especially
> > > on non-i386 it often feels like downloading and installing together
> > > needs less time than the md5sum-verification.
> > > So this should be switched off, but then it will be missing when one
> > > needs them.
> >
> > The md5sum file should be generated at build time, signed and only the
> > signature kept. The signature is small enough not to cause bloat, it
> > can be included in the Package file or a Signatures.gz file containing
> > all signatures could be maintained in the archive.
>
> That still adds the burden of calculating them all after installing.
Only if you need/want to verify.
> I also think it is hardly possible to regenerate the .md5sums file
> in a way the signature will be kept. It would need to never change
> which files are included and how they are sorted. It could also
> cause problems with more sophisticated Replaces and may bite with
> other things I cannot even think about.
dpkg has a list of all files of each package and they can be easily
sorted.
In theory dpkg-repack should build debs with the same signature. In
praxis the original conffiles are frequently missing, happens when you
have edited the file and never updated after that. Otherwise a
dpkg-orig file is there. But thats fixable and should be fixed anyway
for 3-way diffs.
> > > Its also a warm feeling to run debsums to see the broken memory chip
> > > one just replaced with a working one has not caused any bit-changes
> > > in the installed files. If the checksums were created at the same
> > > system, one has to get them from somewhere else, so there is little
> > > sense in having them generated at all.
> >
> > The signature of the locally generated ones wouldn't match the one in
> > the Packages or Signatures file. If the Packages/Signatures file has
> > been tampered with itself (passed through bad memory) one gets a few
> > false negatives but never (1:874584575... whatever the hash size is
> > there) a false positive.
>
> Only if there is a reliable way to regenerate them at instalation time.
> And if one decided to save the time to calculate them or save the space
> by freeing the generated .md5sums file, bringing the system back in a
> state where such integrity can be checked is almost equivalent to
> a reinstall, while extracting the classical .md5sums file from an
> package pool (local mirror, set of CDs ...) and putting them back in
> place is very simple and needs far less processing power.
No, if the originals of the conffile are kept you should be able to
dpkg-repack any deb at any time. Otherwise the deb has been tampered
with (rightfully or not) and not just configured.
You also need to compute the md5sum of all files. Generating a sorted
list of those per package and verifying a signature is hardly more
work than comparing the md5susms file itself. The main burden will be
generating the md5sums in the first place.
You see, you safe the space for the md5sum, you don't waste time (just
the signature verify instead of cmp), everybody downloads less (no
md5sums file in the debs) and you are still more secure and tamper
proof.
MfG
Goswin
Reply to: