Re: checksums situation

[Denys Dmytriyenko <denis@denix.org>]

On Wed, Feb 25, 2009 at 09:09:40AM +0000, Richard Purdie wrote:
> On Tue, 2009-02-24 at 22:29 +0000, Phil Blundell wrote:
> > I think Tom Rini's point, which is a good one, was that the existing
> > checksums.ini workflow doesn't actually do anything to protect against
> > those threats, since there isn't any validation of the checksum against
> > an authoritative source.  Right now, the checksum that you get in
> > checksums.ini is just what was computed by the first person to build the
> > corresponding .bb file: if the file had been compromised before that, we
> > would never know.
> > 
> > Even in the case where the upstream tarball changes unexpectedly, I
> > wouldn't be at all surprised if some or other developer just decided
> > that the checksums.ini entry was wrong and quietly checked in a
> > "correction" for it.  So I tend to agree with Tom, the checksums in
> > their current form do not really buy much.
> 
> I think checksums.ini even in its current form is useful. If the
> checksum matches it tells us that your build configuration at least
> matches the configuration the original recipe submitter had. It also
> spots corrupted downloads and cases where upstream changes and we have
> seen those cases. People shouldn't be silently checking in those changes
> and if they do, would most likely get spotted by people with the old
> version in DL_DIR.
> 
> So to say it does buy much isn't really fair although I agree if you
> want verification of the sources at every level, its not good enough. If
> we want to do better, all it takes is someone to do the work. We could
> have a "verified-checksums.ini" file with some policy attached to it
> which is used instead of or supplements checksums.ini...
> 
> For overlays, I'd suggest just scanning the overlay directories (BBPATH)
> for more checksum.ini files like we do with conf/class files...

Richard,

I'm not in the position to explain how Bitbake works to the Bitbake's core 
developer and maintainer. :) So, below is just my understanding of how it 
works.

So, for overlays it currently works the same way for checksums.ini as it does 
for conf/class files - it uses only one instance of a file with the same name, 
depending on the priority either from overlay or from upstream org.oe.dev. In 
other words - if my overlay has a higher priority, it would use my 
checksums.ini INSTEAD of the upstream one in org.oe.dev. Same with conf/class 
files - if I have a copy of base.bbclass in my overlay, it REPLACES the one 
from upstream org.oe.dev...

Are you suggesting to simply combine checksums.ini files from overlay and 
org.oe.dev? That may work as long as duplicates are handled properly - I guess 
they can be overwritten based on the priorities - i.e. the entry with higher 
priority would replace the duplicate one. But it is not the way it works now. 
And this will definitely not work for conf/class files...

Or maybe I'm just completely missing your point.

-- 
Denys