[Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348

[Thomas Petazzoni <thomas.petazzoni@bootlin.com>]

Hello,

On Thu, 15 Nov 2018 20:05:58 +0100, Yann E. MORIN wrote:

> >  Since we have the same problems sometimes with github tarballs, I think we need
> > a more fundamental solution. I would propose a new tarsha256 hash type, which
> > extracts the tarball to calculate the hash. In a simple version it's not so
> > complicated, something like
> > 
> > tar -xf - --to-command=$(TOPDIR)/support/scripts/tarsha256 | sort | sha256sum -
> > 
> > where tarsha256 contains:
> > 
> > { echo $TAR_FILENAME; echo $TAR_MODE; echo $TAR_FILETYPE; cat - } | \
> > 	sha256sum - | cut -f 1 -d ' '
> > 
> > As usually, entirely untested.  
> 
> I don't like it, because this is totally non-standard. People expect to
> be able to check hashes by running the *usual* XXXsum commands, directly
> on the shipped/received files.
> 
> Introducing our own hash mechanism, how reliable or simple as it would
> be, breaks this assumption, and the tool to actually check them is not
> available at all except internally to Buildroot, so it is not possible
> to reproduce the checks outside of Buildroot.
> 
> This goes counter one of the initial goal of hashes, which is to be able
> to track archives and their validity across a supply chain, inbound (as
> sent by a provider to Buildroot, to do the build) or outbound (as received
> by a recepient, from Buildroot, for compliance) alike.

I understand this argument, but do you have some alternative solution ?

Even building our own host-tar and host-gzip doesn't solve entirely the
problem, because it doesn't solve the case of tarballs fetched from
github, that tend to change in subtle ways once in a while.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com