Re: apt-diff: a tool to diff filesystem content against APT
> On Fri, Dec 10, 2010 at 10:30:02PM -0600, Peter Samuelson wrote:
> > "Note that this information is redundant" - that's rich. As though
> > the entire md5sums file weren't redundant. (I.e., could easily be
> > generated at unpack time.) People seem to hold on to their reasons
> > why it's important to have these integrity checks in the .deb itself,
> > not just on the installed system, but ... yeah.
[brian m. carlson]
> IIRC, the reason md5sums of conffiles are shipped is to determine
> whether they have been changed by the administrator so that dpkg
> knows whether to automatically replace them with newer versions or
> not.
Yes, I know. But the fact that these checksums are needed for dpkg's
conffile functionality doesn't make them any less redundant. dpkg
could just as well generate them just-in-time, at unpack time. That
is, after all, what ucf does. And same for the md5sums file that
covers the non-conffiles.
It's such an unimportant issue that I'm not volunteering to do the work
to make dpkg do this md5summing so the rest of us don't have to. Just
getting some amusement out of someone having implied that shipping md5s
of non-conffiles is _not_ redundant.
> As for integrity checks, which serve a different purpose, MD5 is
> completely inadequate for this, since it is possible to generate
> arbitrary collisions for it.
Oh, this wasn't about whether the checksums that are under control of
the same person who provided the rest of the .deb file are useful for
security purposes. Either you trust the entire .deb file (by, e.g.,
tracing it back to a Release.gpg file) or you don't. Whether this file
which you do or don't trust happens to contain internal checksums using
MD5 or CRC32 or SHA-65536 doesn't even enter into it. Unless there's
also an external source for these checksums, similar to the Contents
files, that won't be under control of the same attacker who corrupted
your .debs.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Reply to: