Re: md5sum proposal
Anthony Towns <aj@azure.humbug.org.au> writes:
> [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.
> > 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. And you can allways get a keyring from a maintainer (if you
know/trust one), which has access to the master keyring, or you can
crosscheck the pgpkeys with other pgp keyrings and key services. If
your real paranoid, visit each maintainer personally.
> Also, the maintainers scripts (preinst, postinst in partiuclar) aren't
> included in .md5sums, so they could be changed without affecting the
> validity of signature. And since they're run as root, that ain't good.
>
> Taking an md5sum of the control.tgz and data.tgz components as a whole
> and signing these would be somewhat more `secure' and certainly no
> more difficult.
Yep. Saying that xxx has no sum doesn't hold, since it could allways
be include. :)
> > 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. After
that you generate md5sums of all files (or just changed ones) and sign
that (or put that onto the removeable as well). Only that way you can
later detect unallowed changes. Generating the md5sums on the fly
doesn't allow checking of config files.
> md5sums can help security, but only in the same sense as not releasing
> your source code does. It raises the bar a bit, but if you're not careful
> makes you disgustingly overconfident.
>
> For system recovery purposes, though -- and seeing what you have to
> reinstall, or what you munged when you did a make install as root when
> you shouldn't have, or whatever, .md5sums don't seem all that bad to me.
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.
> > 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.
> Cheers,
> aj
>
> [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.
May the Source be with you.
Goswin
Reply to: