All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Korsgaard <peter@korsgaard.com>
To: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
Cc: Ricardo Martincoski <ricardo.martincoski@datacom.com.br>,
	"Yann E. MORIN" <yann.morin.1998@free.fr>,
	Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Subject: Re: [Buildroot] [PATCH] utils/check-package: new check for Buildroot's defconfig files
Date: Thu, 16 May 2024 11:27:02 +0200	[thread overview]
Message-ID: <87v83ep0nt.fsf@dell.be.48ers.dk> (raw)
In-Reply-To: <20240501215127.2d729695@windsurf> (Thomas Petazzoni via buildroot's message of "Wed, 1 May 2024 21:51:27 +0200")

>>>>> "Thomas" == Thomas Petazzoni via buildroot <buildroot@buildroot.org> writes:

 > On Sun, 31 Mar 2024 22:34:03 +0200
 > "Yann E. MORIN" <yann.morin.1998@free.fr> wrote:

 >> Now that we do have support for checking hashes for custom versions
 >> (for the few packages for which we do support custom versions, like the
 >> kernel, some bootloaders...), we want to ensure that our defconfig
 >> files, when they enable one or more such custom version, do enable
 >> checking the hashes for those versions, and thus we want to require all
 >> our defconfigs do enable BR2_DOWNLOAD_FORCE_CHECK_HASHES.
 >> 
 >> Add a check for that condition.
 >> 
 >> We need to be careful that we only check Buildroot's defconfig, whether
 >> in-tree or in a br2-external, and not kernel or other kconfig-based
 >> defconfig files, like those in board/ sub-directories. So we only match
 >> defconfig files that are in a configs/ directory, whether at the
 >> toplevel (for in-tree defconfigs), or not (for br2-external defconfigs).

I wonder if it really makes sense to enforce this for br2-external
defconfigs, as it is basically a question about policy and they are "out of
our hands". Depending on the use case it may or may not make sense for
those defconfigs to use hashes.

E.G. at $WORK I have a br2-external tree where check-package is used to
ensure that the packages are well behaved (E.G. do not negatively impact
the rest), but E.G. the kernel is downloaded from a trusted git server
and changed often, so the overhead of maintaining hashes of the
(buildroot internally generated) tarball is quite annoying.

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

      reply	other threads:[~2024-05-16  9:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-31 20:34 [Buildroot] [PATCH] utils/check-package: new check for Buildroot's defconfig files Yann E. MORIN
2024-05-01 19:51 ` Thomas Petazzoni via buildroot
2024-05-16  9:27   ` Peter Korsgaard [this message]

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=87v83ep0nt.fsf@dell.be.48ers.dk \
    --to=peter@korsgaard.com \
    --cc=buildroot@buildroot.org \
    --cc=ricardo.martincoski@datacom.com.br \
    --cc=thomas.petazzoni@bootlin.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.