All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: "Martin Zeiser \(mzeiser\)" <mzeiser@cisco.com>, buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/3 v2] support/download: teach dl-wrapper to handle more than one hash file
Date: Tue, 07 Nov 2023 11:46:16 +0100	[thread overview]
Message-ID: <87a5rpyh6v.fsf@48ers.dk> (raw)
In-Reply-To: <e9097a9727dce27b9124e803a6c0a58091ec3e34.1699297749.git.yann.morin.1998@free.fr> (Yann E. MORIN's message of "Mon, 6 Nov 2023 20:09:12 +0100")

>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:

 > Currently, we expect and only use hash files that lie within the package
 > directory, alongside the .mk file. Those hash files are thus bundeld
 > with Buildroot.

 > This implies that only what's known to Buildroot can ever get into those
 > hash files. For packages where the version is fixed (or a static
 > choice), then we can carry hashes for those known versions.

 > However, we do have a few packages for which the version is a free-form
 > entry, where the user can provide a custom location and/or version. like
 > a custom VCS tree and revision, or a custom tarball URL. This means that
 > Buildroot has no way to be able to cary hashes for such custom versions.

 > This means that there is no integrity check that what was downloaded is
 > what was expected. For a sha1 in a git tree, this is a minor issue,
 > because the sha1 by itself is already a hash of the expected content.
 > But for custom tarballs URLs, or for a tag in a VCS, there is indeed no
 > integrity check.

 > Buildroot can't provide such hashes, but interested users may want to
 > provide those, and currently there is no (easy) way to do so.

 > So, we need our download helpers to be able to accept more than one hash
 > file to lookup for hashes.

 > Extend the dl-wrapper and the check-hash helpers thusly, and update the
 > legal-info accordingly.

 > Note that, to be able to pass more than one hash file, we also need to
 > re-order the arguments passed to support/download/check-hash, which also
 > impies some shuffling in the three places it is called:
 >   - 2 in dl-wrapper
 >   - 1 in the legal-info infra

 > That in turn also requires that the legal-license-file macro args get
 > re-ordered to have the hash file last; we take the opportunity to also
 > move the HOST/TARGET arg to be first, like in the other legal-info
 > macros.

 > Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com>
 > Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
 > Cc: Peter Korsgaard <peter@korsgaard.com>

 > ---
 > Changes v1 -> v2:
 >   - restore legal-info  (Peter K.)

Committed, thanks.

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

  reply	other threads:[~2023-11-07 10:46 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-06 19:09 [Buildroot] [PATCH 0/3 v2] support/download: accept user-provided list of extra hash files (branch yem/multi-hash) Yann E. MORIN
2023-11-06 19:09 ` [Buildroot] [PATCH 1/3 v2] support/download: teach dl-wrapper to handle more than one hash file Yann E. MORIN
2023-11-07 10:46   ` Peter Korsgaard [this message]
2023-11-10 13:36     ` Peter Korsgaard
2023-11-06 19:09 ` [Buildroot] [PATCH 2/3 v2] package/pkg-download: lookup hash files in global-patch-dir Yann E. MORIN
2023-11-07 10:47   ` Peter Korsgaard
2023-11-10 13:36   ` Peter Korsgaard
2023-11-06 19:09 ` [Buildroot] [PATCH 3/3 v2] pkg-download: add option to enforce hash checking Yann E. MORIN
2023-11-07 10:48   ` Peter Korsgaard
2023-11-10 13:36   ` Peter Korsgaard

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=87a5rpyh6v.fsf@48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@buildroot.org \
    --cc=mzeiser@cisco.com \
    --cc=yann.morin.1998@free.fr \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.