Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Yann E. MORIN <yann.morin.1998@free.fr>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348
Date: Thu, 15 Nov 2018 20:05:58 +0100	[thread overview]
Message-ID: <20181115190558.GM10271@scaer> (raw)
In-Reply-To: <016ed0ed-6489-2fa0-a32e-9f2a6918af01@mind.be>

Arnout, All,

On 2018-11-14 00:54 +0100, Arnout Vandecappelle spake thusly:
> On 13/11/2018 21:29, Yann E. MORIN wrote:
> > On 2018-11-13 21:02 +0100, Thomas Petazzoni spake thusly:
> >> On Tue, 13 Nov 2018 18:20:57 +0100, Marcin Niestr?j wrote:
> >>> I think the overall conclusion is that a host-gzip package is needed,
> >>> just like host-tar. In the meantime I will send v3 of this patch with
> >>> proper hash (the same as you calculated above).
> >> This is getting really horrible.
> > Well, we only need host-tar and host-gzip when creating tarballs, not
> > extracting them, correct? So, we could very well envision the fact that
> > host-tar (and host-gzip) are only added to FOO_DOWNLOAD dependecies when
> > FOO_SITE_METHOD == git (and they are needed, of course), no?
> 
>  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.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

  reply	other threads:[~2018-11-15 19:05 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-08 15:33 [Buildroot] [PATCH v2] linux-firmware: bump version to latest 1baa348 Marcin Niestroj
2018-11-09 20:57 ` Thomas Petazzoni
2018-11-09 21:06   ` Yann E. MORIN
2018-11-13 17:20     ` Marcin Niestrój
2018-11-13 17:32       ` Marcin Niestrój
2018-11-13 20:02       ` Thomas Petazzoni
2018-11-13 20:29         ` Yann E. MORIN
2018-11-13 20:57           ` Thomas Petazzoni
2018-11-13 23:54           ` Arnout Vandecappelle
2018-11-15 19:05             ` Yann E. MORIN [this message]
2018-11-16  8:35               ` Thomas Petazzoni
2018-11-20 18:50                 ` Yann E. MORIN
2018-11-20 23:47                   ` Arnout Vandecappelle
2018-11-21  7:13                     ` Peter Korsgaard
2018-11-13 21:34         ` Marcin Niestrój

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181115190558.GM10271@scaer \
    --to=yann.morin.1998@free.fr \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox