From: Thomas Petazzoni via buildroot <buildroot@buildroot.org>
To: jwood+buildroot@starry.com
Cc: Justin Wood <jwood@starry.com>,
"Yann E . MORIN" <yann.morin.1998@free.fr>,
buildroot@buildroot.org
Subject: Re: [Buildroot] [PATCH 1/1] package/pkg-download: add per package download fallback disable
Date: Sat, 17 Sep 2022 20:52:53 +0200 [thread overview]
Message-ID: <20220917205253.3737d1c6@windsurf> (raw)
In-Reply-To: <20220908152330.2588951-1-jwood+buildroot@starry.com>
Hello Justin,
On Thu, 8 Sep 2022 11:23:30 -0400
jwood+buildroot@starry.com wrote:
> From: Justin Wood <jwood+buildroot@starry.com>
>
> This is useful in cases where a package is added without hashes (e.g. private packages)
> and you do not want to risk MITM attacks of the package itself. While still allowing
> download of packages that are third party with hashes, from unreliable upstreams.
>
> This adds a new ${PKG}_DISABLE_FALLBACK_DOWNLOAD that is checked when DOWNLOAD would be
> called to not include URIs from the backup site.
>
> Additionally we use the new backup URIs if the new variable is unset in the json data
> URI list to ensure consistency for consumers who do not use this feature.
>
> Signed-off-by: Justin Wood <jwood@starry.com>
We just had a discussion with Peter Korsgaard, and it seems like we
agree with the feedback from Yann. If you're really concerned about
MITM attacks, you should have hashes in your packages, and generally
speaking if you're concerned about "leaking" information about the fact
that you're building something, you should disable using
BR2_BACKUP_SITE.
However, instead of just saying no to this, we put a bit of thought
into it. What we don't like is that you're adding yet another very
specific variable that touches a very particular aspect of the package
behavior. Instead, we are thinking it might make sense to have a
variable that tells Buildroot the package is "private" or "internal"
(or some other similar naming), as opposed to the rest of the
open-source packages. This could tell Buildroot to not use the backup
site for this package, but also not mention the package in the
legal-info output. It should be noted that we already have the
<pkg>_REDISTRIBUTE = YES/NO boolean, but it only controls whether the
source code gets copied into the legal-info output: even with
<pkg>_REDISTRIBUTE = NO, the package gets listed in the legal-info
manifest. I personally believe it would make more sense to have a
variable that says the package is internal/private, and from that
derive the necessary tweaks to the download and legal-info behavior. I
don't have a good name for this variable though :-/
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
next prev parent reply other threads:[~2022-09-17 18:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 15:23 [Buildroot] [PATCH 1/1] package/pkg-download: add per package download fallback disable jwood+buildroot
2022-09-11 7:47 ` Yann E. MORIN
2022-09-17 18:52 ` Thomas Petazzoni via buildroot [this message]
2024-04-30 17:56 ` Flávio Tapajós
2024-04-30 18:08 ` Yann E. MORIN
2024-05-01 19:09 ` Arnout Vandecappelle via buildroot
2024-05-01 19:46 ` Yann E. MORIN
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=20220917205253.3737d1c6@windsurf \
--to=buildroot@buildroot.org \
--cc=jwood+buildroot@starry.com \
--cc=jwood@starry.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox