On Mon, 18 Jan 2010, Denys Dmytriyenko wrote:
> On Sun, Jan 17, 2010 at 09:45:13AM -0500, Robert P. J. Day wrote:
> > On Sat, 16 Jan 2010, Denys Dmytriyenko wrote:
> >
> > > Using checksums.ini to store checksums was the old default
> > > method and is not recommended any more. It is recommended now to
> > > store checksums in SRC_URIs of the corresponding recipes. Is it
> > > more clear now?
> >
> > got it, thanks. so, based on that, i assume there are no plans
> > for an "sha*sum" SRC_URI parameter as it would seem that an MD5
> > sum is more than sufficient to identify simple download
> > corruption. an additional sha*sum parameter would be overkill.
> >
> > also, given that only about a dozen .bb files incorporate an
> > md5sum parameter at the moment, it's going to be quite some time
> > before this migration is complete and checksums.ini goes away,
> > unless there's some kind of plan to automate inserting that
> > parameter in each and every .bb file.
>
> The initial post from Phil[1] I linked before has this at the end:
>
> ===============
> Next steps:
>
> - figure out a way to implement sha256sum checking, either by extending
> the code in bitbake's fetcher or by providing equivalent functionality
> in base.bbclass
>
> - work out a migration strategy: is it feasible to splice the existing
> checksums into the SRC_URIs programmatically? RP thinks yes. PB
> suggests leaving the existing checksums.ini as read-only and switching
> to checksums incrementally for new packages. RP: can make a git hook to
> allow deletion from checksums.ini but no other changes.
> ===============
ah, thanks, obviously i could have spent a few more minutes reading.
my bad, i apologize.
> BTW, shasum is helpful, as couple years ago it was proven md5 is prone to
> collisions...
ok, but this raises the question as to what the checksums are trying
to protect against. if it's simple (accidental) download corruption,
then an md5sum would be more than adequate. if it's spoofing or
deliberate hacking and md5 is inadequate, why support md5 at all? why
not just *exclusively* use sha256 and drop support for md5 altogether?
or am i misunderstanding something here? perhaps i'll go off and
read that entire thread beginning to end as soon as the coffee is
ready. thanks.
rday
--
========================================================================
Robert P. J. Day Waterloo, Ontario, CANADA
Linux Consulting, Training and Kernel Pedantry.
Web page: http://crashcourse.ca
Twitter: http://twitter.com/rpjday
========================================================================
_______________________________________________
Bitbake-dev mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/bitbake-dev