[oe] checksums situation

[GNUtoo]

> 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.
Sorry I misunderstood his point...
so I think that Generating the url in a way or in another is a good idea
Denis.