"Bernhard R. Link" <[EMAIL PROTECTED]> writes:
> * 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.
Files get corrupted on your system, files disapear, file get edited
legally, postinst/debconf change files, files get replaced, ....
Using/Providing signatures of the md5sum files prevents tampering
(including accidental). The rest remains but I consider them dpkg bugs
mostly.
> In what respect is it not elegant?
>
> And what tamper is it accessible for, that generating at install time
> is not?
To the evil attacker or filesystem corruption.
> > > 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
No, you need to compute the md5sum of all files to do an actual
audit. You already have the list of md5sum file then and just have to
check the signature instead of checking again
var/lib/dpkg/info/*.md5sum.
> installation of a package. (As there is currently to way to do it
> later, and making sure there is will not be easy).
The way to create them later is just as well working as comparing the
current md5sum files. You don't loose anything. And if thats not well
enough you have the _option_ to spend a miniscule amount of extra time
to generate the md5sum lists on install.
> > 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
dpkg bug as said before. And the current md5sum lists approach fails
just as well.
> > > 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.
You generate the signature at build time. You can verify if the md5sum
list you generate at any time or the list a friend gives you (or you
download from snapshot.debian.net) matches the one the maintainer had.
Imagine that, you could trsut snapshot.debian.net not to be
compromised.
> > > 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).
Thats ~1000 out of 8000 packages, 1 arch out of 11 (say 10 to account
for -all packages. So thats 768MB of data for the mirrors. Even with
compression of factor 3 thats 256MB we don't need.
> Hochachtungsvoll,
> Bernhard R. Link
MfG
Goswin
