* Goswin von Brederlow <[EMAIL PROTECTED]> [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.