Verify the var-key attestation on the composed sysroot

[jetm]

Problem

meta-avocado gates the /var key provider at three build-time tiers, and none of
them runs on the path a device actually receives. Two read cryptsetup-var's own
datastore, which a .bbappend can clear; the third hangs off a Yocto image
recipe's ROOTFS_POSTPROCESS_COMMAND, and this tool composes a sysroot from the
feed's RPMs without building an image.

The tree already knew this: avocado-security-capabilities.bb exists precisely
because the image-scope artifact never reached a jetson-orin-nano.

So a machine can declare encrypted-var, ship a substituted unlock path, and
have every build-time check pass or never run. On first boot cryptsetup-var.sh
reads the declaration, runs the provider, and either /var never unlocks or it
opens on a key every device in the fleet shares.

Solution

What survives into the RPM is each script on the unlock path plus the .sha256
that cryptsetup-var's do_install writes beside it after its deliverability
checks pass. Verifying those pairs on the composed sysroot re-arms the gate for
this path.

Key changes

• generate_var_key_attestation_script emits the check; verify_var_key_attestation runs it in the SDK container against the composed sysroot.
• Covers every component meta-avocado attests: cryptsetup-var.sh, var-key.sh, the optional var-hwkey.sh, and cryptsetup-var.service. The unit is included because its ExecStart= names which script performs the unlock and its ConditionPathExists= gates the unit, so editing it substitutes or skips the whole path without changing a script digest. The check also requires the initrd-root-fs.target.wants symlink, since deleting that disables the unit while every digest still matches.
• Decides on the SET rather than on the provider. The first shape exited before the first component check whenever var-key.sh was absent, so on a rootfs the higher-value target was checkable only at the attacker's discretion.
• Runs on the install-stamp short-circuit as well as on a fresh install. A stamp records install INPUTS and stays current when nothing about the request changed; it says nothing about the sysroot's CONTENTS, which is all this check reads.
• Refuses a swapped script, a missing attestation, a symlink at any path component, a partial component set, and an absent unlock path on the initramfs.
• Canonicalises the sysroot once and prefix-compares, so a non-canonical AVOCADO_PREFIX no longer refuses a clean sysroot.
• Every refusal exits rather than returns, so a refusal cannot degrade to an unread warning if set -e is ever disarmed at the call site.

Reviewer notes

Rollout order is a hard dependency, and this should not merge first. A feed
built before meta-avocado writes the attestation has no .sha256 and is
refused, not warned. Measured, rc=1, against a sysroot composed from a real
pre-change RPM. meta-avocado ships first, feeds rebuild, then this.

Softening the missing-attestation case to a warning would reintroduce exactly
the silent pass this removes.

The component list is a hand copy across a repo boundary. It mirrors
avocado_var_key_attested_components() in
avocado-security-capabilities.bbclass, and nothing binds the two. The
alternative considered and rejected was shipping a manifest of what to check
beside the digests, which puts the set of things-to-check in the same
attacker-writable directory as the digests.

Verified end to end on a real feed, not only against fixtures. A local
package feed was built from this branch's meta-avocado tree, served over HTTP,
and installed with avocado sdk install followed by avocado initramfs install
into a composed sysroot carrying encrypted-var tpm2 and all four attested
components with their digests. Substituting cryptsetup-var.sh in that sysroot
and re-running the install returns rc=1 naming the file and both digests;
restoring the original bytes returns rc=0.

That E2E is what found the last defect here. The check previously sat below the
install-stamp short-circuit, so it ran once on first install and never again,
and a tampered sysroot passed with rc=0 and no diagnostic. No unit or fixture
test could see it: they exercise the generated script directly, so they cover
what the script decides and not whether the caller asks it.

Twelve fixture cases run the generated script under sh against real sysroot
trees in avocadolinux/sdk:2026-edge, one per decision branch. 1762 lib tests
pass. Mutation-tested: replacing the whole check_component body with
return 0 previously left every test green and now fails two.

Draft until the meta-avocado side lands and feeds rebuild.