Re: checksums situation

[Richard Purdie <rpurdie@rpsys.net>]

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...

-- 
RP