[bitbake-devel] [PATCH] data/siggen: Switch md5 -> sha256

Richard Purdie richard.purdie at linuxfoundation.org
Wed Jul 24 08:11:09 UTC 2019


On Tue, 2019-07-23 at 11:59 -0500, Mark Hatle wrote:
> On 7/23/19 11:09 AM, Mike Crowe wrote:
> > On Monday 17 December 2018 at 17:16:45 +0000, Richard Purdie wrote:
> > > Similarly to the codeparser change, change to sha256 hashes due
> > > to worries
> > > over collisions. The main impact of this change is slightly
> > > slower parsing
> > > time as well as longer sstate file names.
> > > 
> > > Signed-off-by: Richard Purdie <richard.purdie at linuxfoundation.org
> > > >
> > 
> > This change has given us several sstate cache filenames that exceed
> > the 255
> > character limit of ext4. :(
> 
> I wonder if another approach might be easier.  Instead use change the
> filename
> to be:
> 
> sstate:<sstate_version>:<hash>:recipe:version:...:task.<type>
> 
> (<type> such as .tgz.signifo)
> 
> If the filename becomes too long, simply truncate the middle section)
> preserving:
> 
> sstate:<state_version>:<hash> and <type>
> 
> So the same truncation when matching, and it should be safe.  The
> recipe,
> version ... task bit is nice to have for a human reader, but I don't
> think it's
> actually needed by the system itself.
> 
> This should avoid any collisions and keep the maximum information
> that will fit
> in the filename(s).

In some ways regardless of what we do, we need to abstract it so that
we have one function generating the filenames.

So yes, think we need a patch which abstracts the filename generation.
It needs to be able to truncate elements of the constructed name other
than the hash. I do prefer truncating the other elements than changing
the hash.

Cheers,

Richard



More information about the bitbake-devel mailing list