Re: debsums for maintainer scripts
* Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031206 05:12]:
> > But false negatives cause work. Why do you want to cause false
> > negatives?
>
> Its not causing it. Its not preventing them anymore than the current
> list.
Huh? I gave multiple examples where the current solution works
correctly, but your suggested solution will give false negatives
unless major work is put into it.
> > I'm still hoping to see you giving a single reason, why the current
> > robust solution, implemented by a vast majority packages, should be
>
> Because its neither robust, not elegant, nor tamper resistant.
So please give me a simple reson or example why it is not robust.
I cannot think of anything more robust than a static file generated
at build time.
In what respect is it not elegant?
And what tamper is it accessible for, that generating at install time
is not?
> > replaced by something else. Where this something else needs substantial
> > computing power, will need much work to be usable in all cases and
>
> As I explained it only need the extra computing power to calculate a
> signature of the md5sums list of a package. The time taken to compute
> a signature of a few K is neglible compared to the time spend
> computing the md5sums of installed files in the first place.
No, it needs the time to calculate all the md5sums before it can
calculate the signature. And it will need this time with any
installation of a package. (As there is currently to way to do it
later, and making sure there is will not be easy).
> Also this is only required when actually verifying and only for people
> who want to do that. People with proper intrusion detection systems
> don't have to.
This simply does not work.
dpkg -i a ; dpkg -i a-replacement ; dpkg -P a-replacement
is simply not equivalent to
dpkg -i a
> > is complex enought that it will eventually fail.
>
> Its just as robust as the current md5sum lists and then failsave on
> top of it. Its not removing any features you can have with the current
> setup but adds security, saves bandwith and space.
How should it add security? If you generate the md5sums at build time
or at install time, it keeps the same.
> > The only thing having any similarity to a reason was the size of those
> > files. But seeing how small they are, I don't think this can be the
> > reason. So what did I miss?
>
> It is a reason. First you have the smaller and embeded systems that
> can realy do with the files, seeing that they are useless for a
> security audit anyway. Second you have all the mirrors wasting
> precious space and bandwith.
Embeded systems is will need some space reductions with other files
anyway. (Or such small files will not cause anything).
The space-save for the mirrors by removing the md5sums files should
be equivalent to dropping a single avarage-sized non-free package.
(If it has a longer description, the bandwidth needed to fetch this
packages Description within Packages.gz each time someone does an
update should also easily compensate the bandwith of the md5sums
of all the other files.)
> As an example: The md5sum list of a package is usually bigger or same
> size as its changes file and there is concern about mirror space and
> bandwith if they should be added to the archive.
Almost all packages have already a md5sums file. So there if few
additionally space needed. For the comparison of the size:
# find /var/lib/dpkg/info/ -name "*.md5sums" -exec ./count.sh {} \; |./avarage.awk
3200.3
# find /usr/share/doc -name "changelog.Debian.gz" -exec wc -c {} \; |./avarage.awk
5310.36
# find /usr/share/doc -name "changelog.Debian.gz" -exec ./count.sh {} \; | ./avarage.awk
5333.54
Where count.sh is gzip < $1 | wc -c and having the md5sums file packaged
in a larger .tar.gz might even cause less space.
(All numbers from my woody system, where 989 out of 1158 packages have
md5sums files).
Hochachtungsvoll,
Bernhard R. Link
--
Sendmail is like emacs: A nice operating system, but missing
an editor and a MTA.
Reply to: