[Buildroot] linux-firmware hash mismatch (tar-1.30)
Arnout Vandecappelle
arnout at mind.be
Mon Jan 22 22:14:08 UTC 2018
On 18-01-18 22:40, Peter Korsgaard wrote:
>>>>>> "Arnout" == Arnout Vandecappelle <arnout at mind.be> writes:
>
> Hi,
>
> >>>> Gaah, what a mess :/
>
> > Note that this also means our github hashes will break again...
>
> Indeed, I also mentioned that earlier.
>
> >> Alas, this means that we can only depend on building our own tar...
>
> > Nah, let's not go there.
>
> >> Even when we eventually support using a local git-clone cache, this we
> >> not solve the issue has the hashes we store are on the generated
> >> tarball...
>
> > However, the way we create a git tarball can serve as a source of inspiration
> > of how to solve it. Instead of hashing the tarball, we can hash the contents of
> > the tarball instead, using --to-command and a support script (--to-command
> > exists since 1.15.90 and our minimal tar version is 1.17). The support script
> > would print the metadata and a hash of the contents. And the output of all that
> > is piped into sort (to make sure the order of files in the tarball isn't
> > relevant) and shasum.
>
> Hmm, that is perhaps an option. It does make it somewhat more cumbersome
> to calculate the expected hash by hand, but maybe that is ok.
There's still a patch floating around that doesn't remove the downloaded file
[1], and the calculated hash is already reported. So not much of an issue I think.
> Alternatively we don't do anything and instead ensure that tarballs on
> s.b.o matches the hashes we commit, and people using incompatible tar
> versions will fall back to the tarballs on s.b.o.
But then they'll still be downloaded twice. Not very nice.
Let's discuss it at the meeting in two weeks.
> > That way we don't rely on the way the user's tar behaves at all. We really
> > check the contents of the tarball. It would also mean we can drop the complexity
> > in the git download helper and directly use git archive.
>
> I thought the main reason for our custom tarball handling was support
> for git submodules? I take it that git-archive still doesn't handle those?
Right, I forgot about that.
Regards,
Arnout
[1] http://patchwork.ozlabs.org/patch/834425/
--
Arnout Vandecappelle arnout at mind be
Senior Embedded Software Architect +32-16-286500
Essensium/Mind http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint: 7493 020B C7E3 8618 8DEC 222C 82EB F404 F9AC 0DDF
More information about the buildroot
mailing list