[Buildroot] [PATCH 1/1] package/pkg-download: add per package download fallback disable

[Thomas Petazzoni]

Hello Justin,

On Thu,  8 Sep 2022 11:23:30 -0400
jwood+buildroot at starry.com wrote:

> From: Justin Wood <jwood+buildroot at 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 at 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