Re: [bitbake-devel] [PATCH] bitbake-setup: pass install-buildtools options from config and CLI

Hi Alex and Richard,

  I am in favour of this approach. Here's what I'm thinking for the implementation:

  1. bitbake-setup downloads the buildtools installer using bb.fetch, with sha256sum specified in the bitbake-setup config (same mechanism as layers). This
  gives us download caching in DL_DIR and checksum enforcement for free.
  2. bitbake-setup then calls install-buildtools --url file://<DL_DIR> --filename <name> --no-check — the --no-check is safe because bb.fetch already
  validated the sha256. (By writing sha256sum from config  into DL_DIR , we can avoid --no-check as well but bit a hacky )

     Two options for install-buildtools here:

     (a) Update install-buildtools to handle file:// URLs natively — uses the file in-place, avoids a redundant copy of a potentially large (~500MB)
  installer to a temp directory.

     (b) Leave install-buildtools unchanged — wget already supports file:// and will copy the file to temp. t requires zero changes to
  install-buildtools, making this a bitbake-only patch.

     I'm fine with either. What's your preference?

  Pros:

  - Buildtools installer is cached in DL_DIR alongside layers and source tarballs — survives upstream disappearing
  - Checksum is in a trusted config file, not fetched from the same server as the installer — protects against supply chain attacks
  - Consistent with how everything else is fetched in bitbake-setup
  - --no-check remains in install-buildtools but is justified — the caller (bitbake-setup) has already done validation via bb.fetch

  Concerns:

  - If sha256sum is omitted from config, bb.fetch still downloads but prints a warning about missing checksum (respects BB_STRICT_CHECKSUM if set)

  Flow when user runs bitbake-setup install-buildtools --setup-dir ./my-setup:

  1. bitbake-setup reads config → gets url, filename, sha256sum
  2. Constructs SRC_URI: "https://downloads.../x86_64-buildtools-...5.3.2.sh;sha256sum=a1b2c3..."
  3. bb.fetch.Fetch downloads to DL_DIR, validates sha256 (hard fail if mismatch)
  4. Calls: install-buildtools --url file://<DL_DIR> --filename <name> --no-check -d ./my-setup/buildtools
  5. install-buildtools uses file, makes executable, runs it, sets up env

  Config format:

  "install-buildtools": {
      "url": "https://downloads.yoctoproject.org/releases/yocto/yocto-5.3.2/buildtools",
      "filename": "x86_64-buildtools-extended-nativesdk-standalone-5.3.2.sh",
      "sha256sum": "a1b2c3d4..."
  }

  If sha256sum is omitted — bb.fetch downloads with a warning (user's choice).
  If sha256sum doesn't match — bb.fetch raises FetchError before install-buildtools is ever called.

  Standalone usage of install-buildtools remains unchanged.

  Does this match what you had in mind?


Regards,
Jaipaul Cheernam


From: Alexander Kanavin <[email protected]>
Date: Tuesday, 16 June 2026 at 16:26
To: Jaipaul Cheernam <[email protected]>
Cc: Richard Purdie <[email protected]>; [email protected] <[email protected]>
Subject: Re: [bitbake-devel] [PATCH] bitbake-setup: pass install-buildtools options from config and CLI

On Tue, 16 Jun 2026 at 16:18, Jaipaul Cheernam via
lists.openembedded.org
<[email protected]> wrote:
> Agreed on removing --sdk-name  and I have sent Patch v2 for review in oe-core.
>
> For --no-check — I'm fine removing it and having the install-buildtools auto-detect, but we need to decide on the failure mode: if the checksum file can't be fetched
> (404 or network error), should we:
>
> (a) warn and continue the install without verification, or
> (b) hard fail and refuse to install?
>
> If (a), we're effectively auto---no-check on failure, which may silently skip validation on transient network issues. If (b), users with custom/local
> URLs that don't host checksum files would have no way to install without us re-adding an override flag or having them to add checksum file.
>
> I checked the history why "--no-check” was added and it was part of bf902a810f98f55dd9e8cb9e6c6b0903f9902157
>
> What's your preference?

Please note my comment in this thread. If we use bitbake fetcher with
checksum in a bitbake-setup config file, then the checksum would be
enforced in a way that is secure against tampering or accidental
replacement.

Alex