Re: debsums for maintainer scripts
"Bernhard R. Link" <blink@informatik.uni-freiburg.de> writes:
> * Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de> [031205 16:11]:
> > With replaced files being kept you can recalculate correct md5sum
> > lists for A and B at any time in any combination of installed
> > packages. But even if it fails due to some bug you will only get a
> > false negative. Then you download the debs and see what the problem
> > is.
>
> 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.
> 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.
> 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.
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.
> 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.
> 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.
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.
MfG
Goswin
Reply to: