fix(packages): make the third-party supply chain verifiable, and its pins real

[Kartikey1306]

The architectural problem

ebuild downloads third-party source over the network and builds it. That makes recipes/*.yaml the tool's supply chain, and a recipe is a pin: a URL plus the digest of exactly what should be at it.

Four of the five shipped recipes are not usable pins, and the code let them ship that way.

The recipes

Each digest below was checked by downloading the artifact twice and hashing it; both downloads agreed.

recipe	recorded	actual
littlefs	sha256:placeholder	9cf2e7db…cad67
lwip	sha256:placeholder	c79255f6…ed87
mbedtls	…b1490fcd73	…b1490fcd38
freertos	e36e5a2f…e3140	eebd58aa…271eb
zlib	9a93b2b7…df23	9a93b2b7…df23 ✅

• mbedtls has the last two hex characters transposed — 73 where the published digest ends 38.
• freertos matches none of the release's assets. That tag publishes exactly one: FreeRTOS-KernelV11.1.0.zip, 3324125 bytes, eebd58aa…271eb.

All four corrected. The practical effect today is that ebuild cannot fetch four of the five libraries it ships recipes for — every attempt dies on a checksum mismatch.

Why nothing caught it

"placeholder" parsed as a valid checksum

PackageRecipe.validate() checked the field's shape in no way at all, so sha256:placeholder sailed through and then failed every fetch. A checksum that is present must now look like a sha256 digest.

It is deliberately still optional at the recipe level — a recipe also models packages that are never downloaded, and requiring it there broke 20 resolver tests that build in-memory recipes. The requirement lands at the boundary that actually matters:

No checksum meant no verification

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

Omitting one field silently bought an unverified download. fetch() now refuses before touching the network.

tests/ebuild/test_package_fetcher.py contained test_empty_checksum_skips_verification, which asserted exactly this behaviour as if it were intended. It is replaced by one asserting the refusal.

Plaintext http:// was accepted

_download() allowed http:// and https:// alike. A pin is worth much less over a transport anyone on the path can rewrite, and it leaks what is being built. https only — no shipped recipe used http.

Keeping it fixed

tests/unit/test_shipped_recipes.py walks recipes/ and asserts each one pins a syntactically real sha256 over an https URL and loads through the real loader. Against the recipes as they were, it fails on both placeholders.

It deliberately does not assert digest values: that needs the network, and pinning them in a test would only duplicate the recipe. Catching the mbedtls-style transposition needs a fetch, which belongs in a scheduled job rather than the unit suite — happy to add one if you want it.

Verification

Check	Result
pytest tests/	223 passed (was 202)

16 new recipe tests, plus the inverted fetcher tests.

Relationship to #66

Independent — different files. #66 restores the package import and the ninja backend; this is the packages/recipes layer. Both are on master as the base.

🤖 Generated with Claude Code

[codecov-commenter]

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

Codecov Report

❌ Patch coverage is 79.16667% with 5 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 ⚠️
ebuild/build/dispatch.py	87.50%	0 Missing and 1 partial ⚠️

📢 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.