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

Re: [RFC] Enhance checksum support

On Sun, Jan 20, 2008 at 01:45:35PM +1000, Anthony Towns wrote:
> On Sat, Jan 19, 2008 at 06:15:45PM +0100, Frank Lichtenheld wrote:
> The advantage of having all that in one place means you can verify the
> hash properly with a simple script like:

Ok, I can see that.

> > So maybe keep the Checksums field and introduce a Contents field that
> > contains no checksums, but only the size and the name?
> > Checksums:
> >   md5 4bf7ff17bd9ddf3846d9065b3c594fb4 foo
> >   sha256 28ee6a10eb280ede4b19c1b975aff5533016a26de67ba9212d51ffaea020ce34 foo
> Having the hash as a parameter instead of in the field is a bit confusing
> but still easy to parse; having the size separated out makes things much
> more awkward though.
> By confusing, I mean things like:
> 	Checksums:
> 	 sha1 a0a53d15d7dbc6a9cdfd1889ae30ba8b3dbf7d94 foo
> 	 md5 4bf7ff17bd9ddf3846d9065b3c594fb4 bar
> become ambiguous -- is it an error, or are you meant to be using md5 to
> verify bar and sha1 to verify foo, along the lines of Tim's suggestion?

Hmm, I don't really see the problem. dpkg-source should always verify
the checksums it has. And at some point it could warn about cases where
is only has a weaker checksum like md5.

The whole thing honestly doesn't do much for security anyway until the gpg
support of dpkg-source is largely improved. For that I have no real concept yet,

> It's also slightly harder to see what hashes are in use -- you can't just
> check the presence of a field, you have to grep the contents of the field.
> For comparison, the Release files use the format:
> 	MD5Sum:
> 	 {md5} {size} {path}
> 	SHA1:
> 	 {sha1} {size} {path}
> 	SHA256:
> 	 {sha256} {size} {path}

OK, in the end only two points are important to me:
1) Each file should be able to have several checksums specified
2) I really don't like having more than one checksum per line since
   that greatly increases the margin for errors and confusion IMHO.

Since both our proposal match these criteria I have no problem
implementing yours instead. And you are indeed correct that it
makes the information easier to read from simple-minded scripts
(for the small price of including redundant information).

I will prepare a patch to implement your proposal as well and give
people one more chance to issue their opinion before merging one
of them.

Frank Lichtenheld <djpig@debian.org>
www: http://www.djpig.de/

Reply to: