> 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/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101212074138.gd13...@p12n.org
