[oe] checksums situation

[Vitus Jensen]

Am Wed, 25 Feb 2009 14:35:36 -0700 schrieb Tom Rini:

> On Wed, Feb 25, 2009 at 09:27:02PM +0000, Vitus Jensen wrote:
>> Am Tue, 24 Feb 2009 19:25:07 -0700 schrieb Tom Rini:
>> 
>> > On Tue, Feb 24, 2009 at 11:01:05PM -0300, Otavio Salvador wrote:
>> > [snip]
>> >> I do belive that the best way to solve it is to have a md5 file
>> >> together with the .bb recipe. This solves the problems for forks,
>> >> derivatives and also makes harder to just use "cat tmp/checksums.ini
>> >> >> conf/checksums.ini".
>> > 
>> > Running a script that will make the .sum file isn't any harder
>> > really. And it's still a "this is the checksum we downloaded" not
>> > "this is the checksum upstream says is correct".
>> ...
>> 
>> But "this is the checksum we downloaded" says that's it's the same
>> version the author of the .bb receipe downloaded, reviewed and tested
>> on his device.  What is the probability that this author downloaded a
>> corrupt but working archive last november and you get the same corrupt
>> archive now?
> 
> See hrw's post earlier where he points out how many checksums are a
> simple fetch and add? :)

Very simple ... but getting the commit of MODIFIED checksum.ini entries 
through unrecognized is much harder.  I have seen discussions about such 
patches here.


>> If you want better security you have to ask the download source for a
>> GPG signature of his files or the like as MD5 isn't really safe.
> 
> This is one of my points.  People think we have security from our
> current checksum list, but we do not.

But even a really safe signature is just an entry in some central or 
distributed checksum.ini, so commiting a different entry would be as easy 
as it is now.

If this leads you to abandon checksums alltogether: the current situation 
protects against corrupt downloads and otherwise undetected updates from 
upstream and I'm all for keeping such a protection.

Bye,
  Vitus

-- 
Vitus Jensen, Hannover, Germany, Earth, Milky Way, Universe (current)