Re: md5sums files
On Wed, Mar 03, 2010 at 02:02:01PM -0600, Peter Samuelson wrote:
>
> [Julien Cristau]
> > > fundamentally, shipping a md5sums file is really just a tradeoff in
> > > download size vs. installation speed, not unlike gzip vs. bzip2. One
> >
> > Only if you assume that disks never fail and thus files never get
> > corrupted when the package gets unpacked.
>
> Given a .deb, turning the data.tar.gz into foo.md5sums is a SMOP.
> This could be before, during, or after the deb is unpacked.
>
If you create the hashes at unpack time, you don't catch errors that
happen during unpack. Why not create them at package build time and
include them? I mean we are talking bytes here for the hashes, not
megabytes. I can't see a download size problem.
> Using the packaged foo.md5sums as an internal consistency check of
> data.tar.gz itself is interesting, but somewhat unwieldy. Better would
> be to checksum data.tar.gz in its entirety. But doesn't gzip already
> do that? (Yes, it's only 32 bits, but we aren't trying to detect
> intentional tampering, only corruption.
The hash must include the whole package, not just data.tar.gz.
> To detect intentional
> tampering, you need signed debs,
Yes, I think that should be the goal.
> or at least signed Packages.bz2.)
You already have this, kind of: the Release file is signed and it contains the
hash of the Packages file, wich in turn contains the hashes for the
packages. The problem here is, that you can only check packages, that
are currently part in some release. If you have an old version lying
around or a package sent to you by someone, you're out of luck. The
package signature should be part of the package.
harry
Reply to: