Re: Mis-generation of shell script (run.do_install)?

[Andre McCurdy <armccurdy@gmail.com>]

On Mon, Dec 17, 2018 at 6:44 AM <richard.purdie@linuxfoundation.org> wrote:
>
> On Sat, 2018-12-15 at 20:19 -0500, Jason Andryuk wrote:
> > As far as I can tell, pysh is working properly - it's just the
> > bb_codeparser.dat which is returning the incorrect shellCacheLine
> > entry.  It seems like I have an md5 collision between a pyro core2-64
> > binutils do_install and core2-32 python-async distutils_do_install in
> > the shellCacheLine.  python-async's entry got in first, so that's why
> > binutils run.do_install doesn't include autotools_do_install - the
> > shellCacheLine `execs` entry doesn't include it.  Or somehow the
> > `bb_codeparser.dat` file was corrupted to have an incorrect `execs`
> > for the binutils do_install hash.
>
> That is rather worrying. Looking at the known issues with md5, I can
> see how this could happen though.

How do you see this could happen? By random bad luck?

Despite md5 now being susceptible to targeted attacks, the chances of
accidentally hitting a collision between two 128bit hashes is as
unlikely as it's always been.

  http://big.info/2013/04/md5-hash-collision-probability-using.html

"It is not that easy to get hash collisions when using MD5 algorithm.
Even after you have generated 26 trillion hash values, the probability
of the next generated hash value to be the same as one of those 26
trillion previously generated hash values is 1/1trillion (1 out of 1
trillion)."

It seems much more likely that there's a bug somewhere in the way the
hashes are used. Unless we understand that then switching to a longer
hash might not solve anything.

> I think this means we need to switch to a better hash mechanism. I've
> sent a patch changing this to sha256 on the bitbake list.
>
> We also probably need to change over the code in siggen for the sstate
> hashes too but one step at a time...
>
> Cheers,
>
> Richard
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core