Re: debsums for maintainer scripts
* 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.
> 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.
> > 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.
> 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 see, you safe the space for the md5sum,
Huh?
# cat /var/lib/dpkg/info/*.md5sums | wc -c
9165770
# 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
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)
Hochachtungsvoll,
Bernhard R. Link
BTW: I don't need your mails twice. Please do either send to me or
the list and not both. Thank you.
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: