[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: md5sum proposal



On Wed, May 19, 1999 at 01:23:48PM +0200, Goswin Brederlow wrote:
> > [1  <text/plain; us-ascii (7bit)>]
> > On Wed, May 19, 1999 at 11:57:54AM +0200, Goswin Brederlow wrote:
> > > 1. If each package had a md5sum file, one could verify the space
> > >    requirements before installing a package.
> > Huh? .md5sums don't have any size information. How would this help?
> Ups, your right. Wasn't there an option to include it as well? From
> md5sum --help it seems not. But that shouldn't be to hard to add.

No, but the sizes are already obtainable anyway:
	dpkg-deb -c *.deb

And this is thus getting off track.

> > > 2. md5sum files in the package could be signed. (secure)
> > Assuming users have some way of getting a trusted key to check it
> > against, and assuming maintainers and auto-builders have some way of
> > signing packages in a way that isn't vulnerable to compromised keys and
> > outdated debian-keyrings, and is still tracable.
> If you don't trust the maintainers there isn't any security
> anyway.

It's not an issue of trusting the maintainers, it's an issue of ensuring
there's some way of limiting your trust so that, for example, if my
hard drive gets stolen and my passphrase gets snooped, the only window
of opportunity for the thief is between the theft and my informing the
the archive managers (or some such), not until potato gets released and
people finally get updated debian-keyring .deb's.

This requires careful thought to get right, not vague handwaving.

> Yep. Saying that xxx has no sum doesn't hold, since it could allways
> be include. :)

Maintainer scripts are specifically excluded at the moment. It's
documented behaviour. So you'd be changing what it is currently. In
addition, if you include maintainer scripts in any of the obvious ways,
you'll find it harder than it is at the moment to verify your md5sums,
or you'll break dpkg's encapsulation of where maintainer scripts go.

And note that for recovery purposes, md5sums of data.tar.gz and
control.tar.gz are completely useless.

> > > 3. After configuration new md5sums can be generated and signed (for
> > >    security)
> > This also has more complicated issues than just generating md5sums (find
> > | xargs will do that for you). In particular making sure your list of
> > md5sums isn't equally vulnerable as your main system is difficult. Signing
> > them in any useful way requires keeping your private key on removable
> > media, (or on a separate secured/firewalled/somethinged computer). Other
> > options are keeping your md5sums on removable media, or write-once media,
> > like CD-R or printing them out in a manner that's verifiable by hand [0].
> > And regenerating md5sums from just installed packages takes at worst about
> > half a minute, so there doesn't seem to be a huge saving here either.
> Installation of packages must be done offline, after booting with a
> removeable medium and after checking the system is still clean. 

At which point you're applying enough effort that having premade .md5sums
is completely irrellevent.

> Only that way you can
> later detect unallowed changes. Generating the md5sums on the fly
> doesn't allow checking of config files.

mount /dev/fd0 /mnt
find /etc -type f -exec md5sum {} \; | sort +1 >/mnt/foo
sync
umount /dev/fd0

find /etc -type f -exec md5sum {} \; | sort +1 >/tmp/bar
mount -o ro /dev/fd0 /mnt
diff /mnt/foo /tmp/bar
umount /dev/fd0

Having premade md5sums doesn't help you here. It's not the default
system's configuration you're interested in, it's your own.

> Thats the main use for it, as I see it. But not only for recovery, but 
> also for backup. You only need to backup files that have a different
> md5sum compared to the deb files on CD.

Or you can not back up anything that was on the CD in the first place,
and only back up /etc, /home, /usr/local, and /var/local, or similar.

We already have policy in place so that that essentially works (although
backing up all of /var is probably a good idea).

> > > What I would like most on md5sum files is that one can tell if a
> > > package would fit before/during installing and that should be
> > > something dpkg or apt should learn.
> > This is more the area of .du files, no? Whatever happened to those anyway?
> > I thought we came up with a good way of doing them sometime last year?
> Put md5sum and du into one file. Make md5sum generate output the size
> as well, so one scan through the package is enough.

Have you even looked at what the .du control file was meant to do? It's
completely different to md5sums in purpose and format.

> > [0] an md5sum of the whole list of md5sums, followed by an md5sum of the
> >     first half, and one of the second half, followed by one of the first,
> >     second, third, and fourth quarters, and so on, will let you do a
> >     binary search for changed files, and give you a fairly easy way of
> >     checking to see whether any of them have changed, for example. Not
> >     for the faint of heart.
> So it takes 5 hours to calculate the md5sums, but then you take not 20 
> seconds to compare, but only 10. Great. :) Pretty worthless.

If you can visually compare two printed lists of over 22000 128bit
numbers in 20 seconds colour me very impressed.

Cheers,
aj

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

       ``There's nothing worse than people with a clue.
             They're always disagreeing with you.'' 
                                 -- Andrew Over

Attachment: pgpR2N4iVuRYQ.pgp
Description: PGP signature


Reply to: