Re: debsums for maintainer scripts
"Bernhard R. Link" <blink@smtp.informatik.uni-freiburg.de> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031204 15:05]:
> > > 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.
>
> They can be easily sorted, after you decided how to sort. I have no
> problems to imagine that filename may have more than just ascii
> characters in the near future or that some sorting rotine may be
> depending on a given locale and other things. This one (other file
> due to different sorting) is the least propable of the three possible
> reasons I mentioned. And things like that have bitten us in other
> situations already...
>
> > In theory dpkg-repack should build debs with the same signature.
>
> Well, I prefer theories whose results agree with reality:
> # ar -p ~admin/blub_1.00-1_i386.deb data.tar.gz | tar -tzf - ./gaga/dada
> ./gaga/dada
> # dpkg -i ~admin/blub_1.00-1_i386.deb
> # cat /gaga/dada
> a
> # dpkg -i ~admin/bla_1.00-1_i386.deb
> # cat /gaga/dada
> b
> # dpkg-repack blub
> dpkg-deb: building package 'blub' in './blub_1.00-1_i386.deb'.
> # ar -p ./blub_1.00-1_i386.deb data.tar.gz | tar -tzf - ./gaga/dada
> tar: ./gaga/dada: Not found in archive.
> tar: Error exit delayed from previous errors.
>
> Both 'blub' and 'bla' are just made by dh_make with an
> mkdir debian/<pkgname>/gaga/dada
> echo <a|b> > debian/<pkgname>/gaga/dada
> instead of $(MAKE) install in debian/rules and debian/control of
> 'bla' habing an additonal Replace: blub in it.
Does "dpkg --purge bla" actually remove /gaga/dada or leave it? Both
ways could leave blub broken. A Bug concerning Replaces has been filed
already and it would show up as false negative which can be verified
in detail by downloading the actual deb.
> > 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.
>
> I'd really prefer to have a working solution in favour of one, that
> starts to be to be fixes and is like to continue to be so.
Package file md5sums don't work any better. You get the samme missing
or changed conffiles and replaced files as with the suggested
method. You loose nothing but gain tamper proofness.
> > > 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.
>
> But I do not want to know, if the packages have been tempered with.
> (Especially as the package management explicitly supports this), but
> I want to know which "files" have changes. Generating the .md5sums file
> locally is - if at all - only possible at installation time. So either
> I have to run the md5sum calculation with any package beeing installed,
> or almost no possibility to get later in that state.
If you generate them when needed you can only say if tampering did
occur. If you generate them at installation time you can say what
files where tampered. If you don't want to spend the little time it
takes to calculate md5sums at install time you loose the ability to
pinpoint files. Its your choice.
> > 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.
>
> No. I have no reason at all to generate the md5sum until I want to check
> the files. At installation time tar already checks for transmitting
> errors.
You need to compute the md5sum of all files upon verifying them. When
you want to check the files. Thats for the option that you don't
generate them at install time.
> > You see, you safe the space for the md5sum,
>
> Huh?
>
> # cat /var/lib/dpkg/info/*.md5sums | wc -c
> 9165770
That 10% of the precious space on my zip rescue disk. Not every
installation of Debian has space to waste.
> # df -h /usr
> /dev/hda2 27G 2.6G 23G 10% /usr
>
> And the count of packages not having md5sums does not save you here:
> # ls /var/lib/dpkg/info/*.list | wc -l
> 1157
> # ls /var/lib/dpkg/info/*.md5sums | wc -l
> 988
>
> > 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.
>
> All I see is waste of time, less security and enough complexity that
1. Md5sums can be computed with several 100 MB/s on the fly while
installing the debs, if one _chooses_ do even do that. Thats hardly
any time.
2. How can you have less security than no security. Current md5sum
iles offer no security at all. Any security is only gained by
downloading a pristine md5sums file which means getting hold of a
pristine deb.
> it is bound to fail. And that compared to an existing, working and
> robust solution that only needs the last some packages to follow.
> And your only reason beeing a ridiculous small amount of
> disc space and bandwidth)
The reason is to have a choice and security.
MfG
Goswin
Reply to: