On Mon, Jan 18, 2010 at 02:50:33AM -0500, Robert P. J. Day wrote: > 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.
The chances are very very low, but it's still possible to get a collision due to a simple download corruption... BTW, there is a way to specify sha256sum in the metadata, defining a name in the SRC_URI and then using the variable flag: SRC_URI = "http://some.address.com/file.ext;name=somename"; SRC_URI[somename.md5sum] = "64a53cd55bc63d3a6f4db742aff90de9" SRC_URI[somename.sha256sum] = "4fb1075ad83f6017616410eff35ada7d567f1ee1b5b23624a817e8fc7dda3f8a" The code to handle this, as Chris mentioned, was added to the OE base.class and not to bitbake, though. -- Denys _______________________________________________ Bitbake-dev mailing list [email protected] https://lists.berlios.de/mailman/listinfo/bitbake-dev
