[oe] checksums situation

[Phil Blundell]

On Tue, 2009-02-24 at 23:10 +0100, GNUtoo wrote:
> *security: that is also very important as threats are growing:
> **nasty threats are growing(at least that's what I heard in the press)
> such as computer infections(malware etc..)
> **intrusion into citizen's computer by the state is legal in some countries:
> http://yro.slashdot.org/article.pl?sid=09/01/04/2042242
> **sometimes distributions repository get compromised
> http://www.vnunet.com/vnunet/news/2224622/red-hat-admits-getting-hacked

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.

If you want true source code verification then there needs to be some
cross-check against a trusted fingerprint from upstream.  The obvious
way to do that would be for upstreams to start GPG-signing the release
tarballs and then we could just verify that the signatures matched.  

Some upstream developers do mention the md5sum of the distribution
tarballs in their release announcements, and in those cases it would
already be possible to verify that the archives are good with a
reasonable degree of confidence.  (Of course, it's possible that all
accessible copies of the release announcement might also have been
compromised, but the likelihood of this being the case diminishes if
they are obtained by a different route to the tarball itself.)  However,
it doesn't seem like even this level of checking is currently being
applied to checksums.ini's contents.

p.