fix(build): config-parity assertion selected the -dbg package #40
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "fix/config-parity-picks-dbg-deb"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
The v7.1.5 build failed in the assertion I added in #35, not in anything it was guarding. Its own message named the culprit:
The -dbg package.
image_debsglobslinux-image-*_${ARCH}.deb, which matches both the concrete image package and the-dbgvariant — and because-(0x2D) sorts before_(0x5F), the-dbgpackage expands first, sohead -n1picked exactly the wrong one every time. The-dbgpackage ships no/boot/config-*at all (its payload is underusr/lib/debug/), so the extraction was empty and the comparison could never succeed.Verified the ordering claim directly:
The kernelrelease derivation further down the same file already skips the
-dbgvariant, with the comment "Skip the -dbg variant." My assertion needed the same skip and didn't have it.Fix, plus three hardenings the failure prompted
.debwas actually found.cmpfiles, rather than piping through a command substitution — substitution strips trailing newlines, and this is a byte-exact comparison.cmpon two empty inputs succeeds, so a wrong package selection or a renamed path would have made this assertion pass vacuously — precisely the failure class this whole change set exists to remove, reintroduced by me in the check meant to prevent it. It now fails with "cannot be evaluated".What the failed build did establish
Worth recording, because it validates the riskiest assumption in #35. The two assertions before this one passed on real output:
The first is the load-bearing kbuild assumption behind the entire in-tree-key change: that a non-default
CONFIG_MODULE_SIG_KEYfilename is not regenerated bycerts/Makefile'sgen_keyrule, so the certificate linked into.builtin_trusted_keysis ours. That could not be tested without a real build. It holds. The second confirms no private key reached a package.So the compile, the key installation, the cert identity and the leak guard are all confirmed good on real output; only my package selection was wrong.
Verification
Tested against hand-built
.debfixtures (an image package with/boot/config-*, a-dbgpackage with onlyusr/lib/debug/), using GNU tar to matchdebian:trixie— macOSbsdtarhas no--wildcards, which is why this could not be caught locally before:/tmppath infinal.config-dbgpackage presentshellcheckandbash -nclean.After merging
mainmoves, so the existingv7.1.5-hardened1tag becomes stale and the guard will reject it. Delete and re-cut:🤖 Generated with Claude Code
The v7.1.5 build failed in the assertion I added, not in anything it was guarding. Its own message named the culprit: the .config shipped in linux-image-7.1.5-...-amd64-dbg_..._amd64.deb differs from the captured final.config. The -dbg package. `image_debs` globs `linux-image-*_${ARCH}.deb`, which matches both the concrete image package and the -dbg variant, and because '-' (0x2D) sorts before '_' (0x5F) the -dbg package expands FIRST -- so selecting it with `head -n1` picked exactly the wrong one every time. The -dbg package ships no /boot/config-* at all (its payload is under usr/lib/debug/), so the extraction was empty and the comparison could never succeed. The kernelrelease derivation further down this same file already skips the -dbg variant, with the comment "Skip the -dbg variant." My assertion needed the same skip and did not have it. Fixed by reusing that selection, and asserting a non-dbg image .deb was actually found. Two hardenings while here, both prompted by the failure: - Extract to a file and cmp files, rather than piping through a command substitution: substitution strips trailing newlines and this is a byte-exact comparison. - Refuse to compare an EMPTY extraction. `cmp` on two empty inputs succeeds, so a wrong package selection or a renamed path would have made this assertion pass vacuously -- precisely the failure class this change set exists to remove, reintroduced by me in the check meant to prevent it. It now fails with "cannot be evaluated" instead. - On a real mismatch, print the leading diff, so the next failure says WHAT differs rather than only that something does. What the failed build did establish, and worth recording: the two assertions before this one PASSED on real output -- embedded cert matches certs/unredacted-signing.pem no .deb contains unredacted-signing.pem The first is the load-bearing kbuild assumption behind the whole in-tree key change: that a NON-default CONFIG_MODULE_SIG_KEY filename is not regenerated by certs/Makefile's gen_key rule, so the cert linked into .builtin_trusted_keys is ours. That could not be tested without a real build, and it holds. The second confirms no private key reached a package. Tested against hand-built .deb fixtures (image with /boot/config-*, -dbg with only usr/lib/debug/) using GNU tar to match debian:trixie, since macOS bsdtar has no --wildcards: correct build passes; a /tmp path in final.config fails (the regression the assertion is for); a -dbg-only directory and an empty-vs-empty comparison both refuse rather than pass. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>