* Peter Samuelson <[EMAIL PROTECTED]> [070818 00:06]:
> I'd opt for dpkg generating the checksums upon _extracting_ the .deb
> file. We already claim that the md5sums file isn't supposed to be any
> kind of security thing. Why bother to ship it? It is redundant
> information which can easily be regenerated on the user's system.
When it is shipped, one is sure that the information in them is what is
supposed in the package. When they are only generated uppon extracting
the package, all it protects are corruptions after installing.
But when you have bad RAM or a faulty disk or DMA settings for your disk,
corruption might more easily occour when something actually happens,
i.e. when the package is installed.
Apt (hopefully, I've not checked this, but all is there, so I guess it
does) checks the file's md5sum uppon retrieval. I'd guess if the apt-method
retrieving it is doing the check, the file written to disk will not be checked
again (and if it is, it is likely that not the file is checked, but what
is in the kernel's cache at that moment). Later when the package is
actually installed (which might be some dpkg runs which each load its
database needing quite some memory which is very likely to reclaim some
memory used for caches before) the image from the disk might be used
which got corrupted by some problem. There is nothing I know of that
would at this point check the md5sum of the package again and even if
it is read two times, one to generate md5sums of the files and one to
extract them, it is likely they produce the same result due to caching,
even if it is only a in memory corruption or a wrong DMA setting
corrupting the read data.
And given that packages that quite corrupted packages got through the
whole archive infrastructure and instalations before (I remember some
package that only apt-listchanges(?) had its problems with as unpacking
it manualy and thus noticing the .gz CRC did not match, while nothing
else did notice that).
If you want to be sure, that the files you have installed have not
been modified by any accident or anything else short of an explicit
attacker (or anything else that updates checksums when it modifies
something.), there is a very simple (and tested solution): generate them
at build time.
(And generating them early makes it also easier to use them in a security
context, as to generate somethine like a live-CD with a trusted kernel
and userspace that lists all files not having default content (though
that would still quite a bit, due to all that automatic generated stuff,
spool files, lock files, data, logs,.....) extracting just the .md5sum
files from a mirror is much easier than to generate them. And when they
are created at build time, there is less chance different versions may
produce different files at install time, so one might actually only
store checksums of the .md5sums files to use those available on the disk
after verification).
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
