[Kartikey1306]

Rebased onto current master and reduced to one change. The supply-chain content this PR opened with — the four corrected pins, the checksum-format validation, and fetch() refusing to download without a digest — is now on master, applied there directly rather than by merging this branch. All of it verified identical, so it is dropped from here.

What remains is the one piece master does not have.

The fixture archive is not reproducible

targz_bytes() builds its .tar.gz with default timestamps, so two calls with the same marker return different bytes:

a = sha256(targz_bytes("x")); sleep(1.1)
b = sha256(targz_bytes("x"))
a == b   # False on master, True with this patch

Every checksum in this module is derived from the helper and then has to match the bytes fake_download hands out later, so the suite is a coin flip on timing — it holds on fast Linux runners and fails on Windows.

Two timestamps default to "now": the tar member header and the gzip header. Writing the tar uncompressed with info.mtime = 0 and compressing through GzipFile(mtime=0) pins both.

16/16 in this module pass, and the digest is now stable across a second boundary.

The CI failure previously on this branch was master's, not this PR's — import ebuild.cli.commands raises NameError: name 're' is not defined, so nine test modules cannot be collected. #97 fixes that.

[codecov-commenter]

⚠️ Please install the to ensure uploads and comments are reliably processed by Codecov.

Codecov Report

❌ Patch coverage is 71.42857% with 4 lines in your changes missing coverage. Please review.

Files with missing lines	Patch %	Lines
ebuild/packages/recipe.py	33.33%	2 Missing and 2 partials ⚠️

📢 Thoughts on this report? Let us know!

[srpatcha]

Verified — and the framing is right

recipes/*.yaml is the tool's supply chain, and treating a recipe as a pin rather than a hint is the correct model. Merged onto current master locally: 223 passed.

The defect that matters most

archive_path = self._download(recipe)
if recipe.checksum:          # ← absent: download and extract, unverified
    self._verify_checksum(archive_path, recipe.checksum)

Omitting one optional field silently bought an unverified download. That is a fail-open default on the one code path where failing open means executing someone else's bytes.

Worse, tests/ebuild/test_package_fetcher.py carried test_empty_checksum_skips_verification — the insecure behaviour was pinned by a test as though it were intended, so anyone who fixed it would have looked like they were breaking something. Replacing that test with one asserting the refusal is the part of this PR I would least want dropped.

Checked the new gate reads the way it should:

Refusing to fetch <name> v<version>: the recipe carries no checksum, so there
is nothing to verify the download against.

Keeping checksum optional on PackageRecipe while making it mandatory at fetch() is the right seam. A recipe also models packages that are never downloaded, and forcing it at the dataclass punished twenty resolver tests that build recipes in memory. The requirement belongs at the boundary where bytes actually arrive.

Independently confirmed one of the digests

I did not re-download all five, but I checked the FreeRTOS claim against the API, since "matches none of the release's assets" is a strong statement:

$ gh api repos/FreeRTOS/FreeRTOS-Kernel/releases/tags/V11.1.0
  FreeRTOS-KernelV11.1.0.zip  3324125 bytes

Exactly one asset, exactly the size and name you record, and the recipe URL points at it. That matches your account precisely.

sha256:placeholder passing validate() is the enabling bug behind all of it — a checksum field that accepts any string is not a checksum field. Requiring the shape when the value is present closes it.

Also right

Rejecting plaintext http:// outright rather than warning. A pinned digest over plaintext is still better than nothing, but there is no reason to accept the downgrade when every URL here is available over TLS.

Verification

Merged onto origin/master; pytest 223 passed; FreeRTOS release assets checked via the GitHub API. Not re-verified: the littlefs, lwip, mbedtls and zlib digests — I am taking those on your stated method of downloading twice and comparing.

[Kartikey1306]

Rebased onto current master — it had gone CONFLICTING, and the branch was also carrying an accidentally committed _build/ directory, which is now gone.

The PR is unchanged in substance: 8 files, the four corrected digests plus the two gates. I re-confirmed the defect is still live on master:

recipes/littlefs.yaml:checksum: sha256:placeholder
recipes/lwip.yaml:checksum:     sha256:placeholder
recipes/mbedtls.yaml:checksum:  sha256:...b1490fcd73     (published digest ends ...fcd38)
recipes/freertos.yaml:checksum: sha256:e36e5a2f...       (matches no release asset)

pytest on the rebased branch: 304 passed, 1 failed. The failure is test_shared_library_uses_shared_link_rule, which fails on master today for an unrelated reason — it asserts the literal -shared while _shared_flag() correctly returns -dynamiclib on macOS. #66 fixes that; nothing here touches it.

Thank you for independently checking the FreeRTOS release assets. That was the claim most worth not taking on trust, since "matches none of the release's assets" is either true or I had made an error, with nothing in between.

[Kartikey1306]

Now stacked on #66 — merge #66 first, which matches the merge order you already published.

Why: enabling the Windows leg (via the ci.yml fix) made this PR's checks run pytest on windows-2022 for the first time, and two tests fail there for reasons #66 fixes and this PR does not touch:

assert ': link ' in 'build C:\Users\...\t.c.o: cc t.c'

— the unescaped drive-letter colon, i.e. exactly the _ninja_path() escaping that lives in #66. My first attempt was to copy the shared hunks into this branch, but the set kept growing (ci.yml, then the shared-flag test, then the ninja escaping, then the golden-path test) until this PR would have effectively contained #66. Stacking is the honest shape: once #66 merges, this PR's diff collapses to the 8 supply-chain files.

pytest on the stacked branch: 312 passed, 0 failed locally; CI now running.